Peter Kovacs, feel free to ping me in case of anything. It's just a hobby for me right now, but I'm interested in this too.
2016-06-03 11:53 GMT+03:00 Peter Kovacs <legi...@gmail.com>: > Cool thanks. Will take a look on the weekend. Thanks for the discussion. > > Alexey Andreyev <yetanotherandre...@gmail.com> schrieb am Fr., 3. Juni > 2016, 10:12: > >> Tone Kastlunger, +1 :) >> >> Peter Kovacs, please, take a look at tracker implementation: >> https://github.com/GNOME/tracker >> It uses semantic nosql techniques to handle the user data (RDF >> ontologies). >> it's focusing on low memory footprint ("Tracker is designed and built to >> run well on mobile and desktop systems with lower memory (256MB or less)"), >> and it is "built around a combination indexer and SQLite database", >> but you can execute sparql queries here. >> So, if you want a graph connections: they are already there. We just have >> to create an apropriate clients. >> >> If you are interested in some other triplestore implementations, also >> take a look at redland rdf libraries^ http://librdf.org/ >> >> 2016-06-02 15:42 GMT+03:00 Tone Kastlunger <users.giulie...@gmail.com>: >> >>> In a distributed fashion it may make sense; >>> speaking of which, doesn't tracker implement a graph db? >>> >>> On Thu, Jun 2, 2016 at 3:40 PM, Andrew Branson < >>> sfdevl...@andrewbranson.net> wrote: >>> >>>> I'm missing how your contacts can be linked as a graph on your phone. I >>>> assumed it was about which of your friends know each other, but that isn't >>>> relevant information on the client side. I don't think it's even easily >>>> available in the main social networks. >>>> >>>> Andy >>>> >>>> On 02/06/2016 2:34pm, Tone Kastlunger wrote: >>>> >>>>> On the RDBMS vs Graph DB's discussion, the point Peter is making is a >>>>> very solid one; >>>>> the purpouse of the contacts app is to mange contacts; hence how they >>>>> are connected; >>>>> if relying on a Graph DB provides a simpler implementation (in terms of >>>>> raw lines of code I mean) in upper implementation levels, >>>>> whilst helping in keeping data consistency in a flawless and >>>>> hassle-free >>>>> way (which SQL can help with only up to a certain extent), >>>>> well it definitely sounds too good to be true (at least from what I >>>>> understood): >>>>> I'd agree with Neo4J on a phone being somewhat of an overkill (same as >>>>> having Postgres for instance); I'd wonder if there are embedded >>>>> versions >>>>> of it? >>>>> I'd say especially within Jolla's Social/Address book/mail/calendar >>>>> contacts management peculiarities, plus the dual SFOS/Android world, it >>>>> requires a >>>>> rock-solid contact management system, I'd assume. >>>>> >>>>> tk >>>>> >>>>> >>>>> On Thu, Jun 2, 2016 at 3:22 PM, Andrew Branson >>>>> <sfdevl...@andrewbranson.net <mailto:sfdevl...@andrewbranson.net>> >>>>> wrote: >>>>> >>>>> Hi! >>>>> >>>>> RDBMSes are not very good at graphs, or trees, or any other data >>>>> structure that requires variable traversal steps in queries. I >>>>> don't >>>>> think we have that here though. Those social networks only have >>>>> graphs when they're integrating your data with other people's, but >>>>> personally you just have your own address book and your own >>>>> calendars. Both of those consist of many instances of the same data >>>>> structures which need to be indexed, which is a good use of >>>>> relational databases. >>>>> >>>>> Your point about SQL being used out of habit is always pertinent >>>>> though. It's important to keep on top of the NoSQL options, as SQL >>>>> is definitely overused. I always find it very irritating when SQL >>>>> is >>>>> used only for config storage, using tables with single rows and >>>>> many >>>>> columns. Berkeley DB would be a good alternative for that. I don't >>>>> know if the graph DBs are ready yet though - Neo4J is very >>>>> interesting, but I would never run a Java server in a phone. >>>>> >>>>> While we're on the subject, I think the Nemo thumbnail DB is a >>>>> really good candidate for a NoSQL database. It's currently a huge >>>>> collection of tiny files that seems to take up way too much BTRFS >>>>> allocation, and I don't think as a collection of binary files it >>>>> would be a good match for SQLite. >>>>> >>>>> Andy >>>>> >>>>> >>>>> On 02/06/2016 1:42pm, Peter Kovacs wrote: >>>>> >>>>> Well SQL is in my opinion good for grouping or conduct >>>>> calculations on >>>>> transactional data. >>>>> Updating, or adding / sorting is not is best discipline. It is >>>>> medicore >>>>> in my opinion. >>>>> On small sets of data as used in phones medicore performance is >>>>> still >>>>> quick. Phones are quite powerfull today. >>>>> >>>>> However the feature the DB should excel should be, in my eyes >>>>> social, >>>>> stuff. It is a phone after all, intended to maintain my social >>>>> life, or? >>>>> >>>>> And Facebook, amazon, google+ does not use relational >>>>> databases. >>>>> They >>>>> use graph databases. So I wonder why this is not used on >>>>> phones. >>>>> Neo4j >>>>> claims to outperform relational databases by a factor of 1000 >>>>> when it >>>>> comes to relationships. >>>>> >>>>> I admit these softwares are very latest technology. And maybe >>>>> not as >>>>> robust as sqllite. >>>>> However I would love to have a contact app which knows that >>>>> Mary >>>>> and Joe >>>>> are married live in the same place. And when I search for one >>>>> of >>>>> the 2 I >>>>> get the shared information. And when I update one end the app >>>>> knows to >>>>> update the other one too. >>>>> Or it can store company hierarchies would help me in my >>>>> business >>>>> life. I >>>>> am not good at memo these. >>>>> >>>>> Yes you can do that with sql. But I think it is easier more >>>>> naturally >>>>> done in a graph db. >>>>> No problem if any one does not agree. I plan to build this >>>>> anyhow. >>>>> >>>>> I am quite unhappy with Google in that because they are not >>>>> doing this >>>>> for me ;) >>>>> >>>>> Btw Object DB is good at storing objects as the name suggests. >>>>> It is >>>>> even more far away from the requirements on a phone then >>>>> relational db >>>>> in my eyes. >>>>> >>>>> All the Best >>>>> Peter >>>>> >>>>> >>>>> Tone Kastlunger <users.giulie...@gmail.com >>>>> <mailto:users.giulie...@gmail.com> >>>>> <mailto:users.giulie...@gmail.com >>>>> <mailto:users.giulie...@gmail.com>>> schrieb am Do., 2. Juni >>>>> 2016, 11:13: >>>>> >>>>> Peter; >>>>> I'm curious, what brings you to the conclusion SQL (as in >>>>> relational >>>>> dbs) is not ideal for transactional functionality? >>>>> >>>>> On Thu, Jun 2, 2016 at 10:41 AM, Peter Kovacs >>>>> <legi...@gmail.com <mailto:legi...@gmail.com> >>>>> <mailto:legi...@gmail.com <mailto:legi...@gmail.com>>> >>>>> wrote: >>>>> >>>>> I would actually like to know why SQL stuff. >>>>> Datastructure types I am think of on the Phone are >>>>> relationships >>>>> (Facebook style) or transactional. >>>>> And both are not ideal to solve with relational dbs. >>>>> >>>>> I guess the Answer is because every one does it. But >>>>> that is not >>>>> really satisfactory. Would there be an interest to >>>>> use >>>>> something else? >>>>> >>>>> >>>>> Tone Kastlunger <users.giulie...@gmail.com >>>>> <mailto:users.giulie...@gmail.com> >>>>> <mailto:users.giulie...@gmail.com >>>>> >>>>> <mailto:users.giulie...@gmail.com>>> schrieb am Do., 2. Juni >>>>> 2016, 09:33: >>>>> >>>>> Hi Chris; >>>>> >>>>> >>>>> >2) API to access Calendar data. Correct, >>>>> currently we >>>>> don't provide access to calendar API in Harbour. >>>>> The reason >>>>> is that we want to use QtOrganizer as the public >>>>> API, but to >>>>> do that we need to write a QtOrganizer engine >>>>> backend >for >>>>> mkcal (note that one already existed in QtMobility >>>>> days, >>>>> which is open source, so we can potentially adapt >>>>> that one >>>>> with relatively little effort. Help with that >>>>> effort would >>>>> be greatly appreciated). Eventually, I'd like to >>>>> develop a >>>>> >QtOrganizer backend directly in sqlite, for >>>>> performance >>>>> and maintainability reasons (mkcal has several >>>>> design and >>>>> implementation problems, in my opinion), at which >>>>> point >>>>> QtOrganizer can become the platform API (not just >>>>> the 3rd >>>>> >party API). >>>>> >>>>> >>>>> I guess the worload to push it all the way to >>>>> QtOrganizer >>>>> requires scratching the existing backend / >>>>> rewriting a big >>>>> part of the cal app? >>>>> >>>>> On Thu, Jun 2, 2016 at 5:06 AM, Chris Adams >>>>> <chris.ad...@jolla.com >>>>> <mailto:chris.ad...@jolla.com> <mailto:chris.ad...@jolla.com >>>>> >>>>> <mailto:chris.ad...@jolla.com>>> wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> I will try to be at the meeting tonight, but I >>>>> cannot >>>>> promise (it's held at 11:30 pm in my >>>>> timezone). >>>>> >>>>> A couple of the questions relate to areas I am >>>>> involved >>>>> with, so I'll try to provide some information >>>>> in case I >>>>> don't make it to the meeting. If you have any >>>>> follow up >>>>> questions or discussion, feel free to contact >>>>> me >>>>> directly via email or on Freenode IRC >>>>> (chriadam >>>>> is my nick). >>>>> >>>>> 1) Contact Note details. This is tracked >>>>> internally by >>>>> JB#14734. As you mentioned, it's supported >>>>> in the >>>>> backend, but not in the People app UI. It was >>>>> on going >>>>> to be part of the apps overhaul which was >>>>> planned prior >>>>> to the financial difficulties last year, and >>>>> since then >>>>> this has fallen off the radar. It requires >>>>> design >>>>> input, because you can have multiple Note >>>>> details in a >>>>> single contact. I've just pinged our lead >>>>> designer in >>>>> the bug report again, in case he can fit it in >>>>> sometime >>>>> soon. >>>>> >>>>> 2) API to access Calendar data. Correct, >>>>> currently we >>>>> don't provide access to calendar API in >>>>> Harbour. The >>>>> reason is that we want to use QtOrganizer as >>>>> the public >>>>> API, but to do that we need to write a >>>>> QtOrganizer >>>>> engine backend for mkcal (note that one >>>>> already >>>>> existed >>>>> in QtMobility days, which is open source, so >>>>> we can >>>>> potentially adapt that one with relatively >>>>> little >>>>> effort. Help with that effort would be >>>>> greatly >>>>> appreciated). Eventually, I'd like to >>>>> develop a >>>>> QtOrganizer backend directly in sqlite, for >>>>> performance >>>>> and maintainability reasons (mkcal has several >>>>> design >>>>> and implementation problems, in my opinion), >>>>> at >>>>> which >>>>> point QtOrganizer can become the platform API >>>>> (not just >>>>> the 3rd party API). >>>>> >>>>> 3) Email app development. Yes, you're >>>>> absolutely right >>>>> that the Email application hasn't received >>>>> much >>>>> development effort since Valerio unfortunately >>>>> left. >>>>> Yes, I would personally like to see it (along >>>>> with other >>>>> apps like Clock, Notes, and Calendar) >>>>> opensourced. No, I >>>>> don't know what the status of the opensourcing >>>>> discussions with the Board Of Directors is, so >>>>> I cannot >>>>> give a roadmap for that possibility. >>>>> However, the >>>>> "engine" of the email application is already >>>>> open source >>>>> (except for the Exchange/ActiveSync plugin) - >>>>> we use QMF >>>>> (Qt Messaging Framework) for email handling. >>>>> See >>>>> https://git.merproject.org/mer-core/qmf and >>>>> https://git.merproject.org/mer-core/messagingframework >>>>> etc for that stuff. Speak to Matt Vogt >>>>> (mvogt on >>>>> Freenode IRC) for code reviews etc. >>>>> >>>>> In general, the Sailfish OS wiki has been >>>>> updated with a >>>>> lot of information about the various software >>>>> components >>>>> which make up the Sailfish OS stack (including >>>>> links to >>>>> the open-source repositories), so you should >>>>> be >>>>> able to >>>>> find most of the information you need to help >>>>> develop >>>>> these components, from reading >>>>> https://sailfishos.org/wiki/Core_Areas_and_APIs and the >>>>> drill-down links from that page. >>>>> >>>>> Finally, I don't know much about Bluetooth, >>>>> but >>>>> I know >>>>> that we're looking at updating to Bluez 5 >>>>> right now >>>>> (development is currently ongoing to port the >>>>> Qt stack >>>>> across, possibly by using the KDE bluez-qt >>>>> wrappers), so >>>>> it's possible that the tethering issue will be >>>>> addressed >>>>> as part of that, with the new stack - but >>>>> again, that's >>>>> not my area so I might be incorrect. >>>>> >>>>> Cheers, >>>>> Chris. >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* devel-boun...@lists.sailfishos.org >>>>> <mailto:devel-boun...@lists.sailfishos.org> >>>>> <mailto:devel-boun...@lists.sailfishos.org >>>>> <mailto:devel-boun...@lists.sailfishos.org>> >>>>> [devel-boun...@lists.sailfishos.org >>>>> <mailto:devel-boun...@lists.sailfishos.org> >>>>> <mailto:devel-boun...@lists.sailfishos.org >>>>> <mailto:devel-boun...@lists.sailfishos.org>>] on behalf >>>>> of James Noori [james.no...@jolla.com >>>>> <mailto:james.no...@jolla.com> >>>>> <mailto:james.no...@jolla.com >>>>> <mailto:james.no...@jolla.com>>] >>>>> *Sent:* Wednesday, June 01, 2016 11:15 PM >>>>> *To:* devel@lists.sailfishos.org >>>>> <mailto:devel@lists.sailfishos.org> >>>>> <mailto:devel@lists.sailfishos.org >>>>> <mailto:devel@lists.sailfishos.org>> >>>>> *Subject:* [SailfishDevel] Sailfish OS Open >>>>> Source >>>>> Community Collaboration Meeting 2nd of June >>>>> 2016 >>>>> >>>>> Hi everyone! >>>>> >>>>> Following up last week’s postponed Community >>>>> collaboration meeting on IRC, this week’s >>>>> meeting is >>>>> going to be held at the agreed time and date, >>>>> 2/6/2016 >>>>> at 13:30 UTC. >>>>> >>>>> Please see this link for your local time >>>>> (Redirects to >>>>> timeanddate.com <http://timeanddate.com> < >>>>> http://timeanddate.com>) >>>>> >>>>> :http://bit.ly/247PwwT >>>>> >>>>> < >>>>> http://redir.aspx?REF=g5j-y9bnU2VIldZnOnr8CS7-bSPOGw-1AMJwEvMljvQjLMD_gYrTCAFodHRwOi8vYml0Lmx5LzI0N1B3d1Q >>>>> .> >>>>> >>>>> Location: #mer-meeting on Freenode IRC >>>>> >>>>> Chairperson: Jaymzz >>>>> >>>>> Duration: Approximately 100 minutes. >>>>> >>>>> Thanks to everyone who has responded and added >>>>> topics on >>>>> >>>>> TJC: >>>>> https://together.jolla.com/question/54157/sailfishos-open-source-collaboration-meeting-planning/ >>>>> >>>>> < >>>>> http://redir.aspx?REF=OlRBTW_rwoaCk_9FOorV7mZrXabeWUP7jnZySM69E7wjLMD_gYrTCAFodHRwczovL3RvZ2V0aGVyLmpvbGxhLmNvbS9xdWVzdGlvbi81NDE1Ny9zYWlsZmlzaG9zLW9wZW4tc291cmNlLWNvbGxhYm9yYXRpb24tbWVldGluZy1wbGFubmluZy8 >>>>> .> >>>>> >>>>> Proposed topics: >>>>> >>>>> -Intro (5min) >>>>> >>>>> -Bluetooth tethering - status of the fix >>>>> (20min) >>>>> >>>>> -2016 roadmap (15min) >>>>> >>>>> -Show notes of contact (opensource contact >>>>> app?) (15 min) >>>>> >>>>> -API to access calendar (15 min) >>>>> >>>>> -Email app development (15 min) >>>>> >>>>> - Requesting things to be added to mer-tools >>>>> repo (5 min) >>>>> >>>>> - General Discussion (5-10 min) >>>>> >>>>> Please familiarize yourself with the topics >>>>> before the >>>>> meeting, as well >>>>> >>>>> as the common Meetbot commands >>>>> https://wiki.debian.org/MeetBot >>>>> >>>>> < >>>>> http://redir.aspx?REF=9bflfCySOf4l8VxPhhLe4rl_8CX0V51Eghusn5jTRNIjLMD_gYrTCAFodHRwczovL3dpa2kuZGViaWFuLm9yZy9NZWV0Qm90 >>>>> > >>>>> (it's >>>>> >>>>> >>>>> used for meeting management and logging) >>>>> >>>>> Best regards, >>>>> James Noori, Community Manager at Jolla >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> SailfishOS.org Devel mailing list >>>>> To unsubscribe, please send a mail to >>>>> devel-unsubscr...@lists.sailfishos.org >>>>> <mailto:devel-unsubscr...@lists.sailfishos.org> >>>>> <mailto: >>>>> devel-unsubscr...@lists.sailfishos.org >>>>> <mailto:devel-unsubscr...@lists.sailfishos.org>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> SailfishOS.org Devel mailing list >>>>> To unsubscribe, please send a mail to >>>>> devel-unsubscr...@lists.sailfishos.org >>>>> <mailto:devel-unsubscr...@lists.sailfishos.org> >>>>> <mailto:devel-unsubscr...@lists.sailfishos.org >>>>> >>>>> <mailto:devel-unsubscr...@lists.sailfishos.org>> >>>>> >>>>> -- >>>>> >>>>> Disclaimer: Diese Nachricht stammt aus einem Google >>>>> Account. >>>>> Ihre Antwort wird in der Google Cloud Gespeichert und >>>>> durch >>>>> Google Algorythmen zwecks werbeanaöysen gescannt. Es >>>>> ist derzeit >>>>> nicht auszuschließen das ihre Nachricht auch durch >>>>> einen NSA >>>>> Mitarbeiter geprüft wird. Durch kommunikation mit >>>>> diesen Account >>>>> stimmen Sie zu das ihre Mail, ihre Kontaktdaten und >>>>> die >>>>> Termine >>>>> die Sie mit mir vereinbaren online zu Google >>>>> konditionen in der >>>>> Googlecloud gespeichert wird. Sollten sie dies nicht >>>>> wünschen >>>>> kontaktieren sie mich bitte Umgehend um z.B. >>>>> alternativen zu >>>>> verhandeln. >>>>> >>>>> >>>>> _______________________________________________ >>>>> SailfishOS.org Devel mailing list >>>>> To unsubscribe, please send a mail to >>>>> devel-unsubscr...@lists.sailfishos.org >>>>> <mailto:devel-unsubscr...@lists.sailfishos.org> >>>>> <mailto:devel-unsubscr...@lists.sailfishos.org >>>>> <mailto:devel-unsubscr...@lists.sailfishos.org>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> SailfishOS.org Devel mailing list >>>>> To unsubscribe, please send a mail to >>>>> devel-unsubscr...@lists.sailfishos.org >>>>> <mailto:devel-unsubscr...@lists.sailfishos.org> >>>>> <mailto:devel-unsubscr...@lists.sailfishos.org >>>>> <mailto:devel-unsubscr...@lists.sailfishos.org>> >>>>> >>>>> -- >>>>> >>>>> Disclaimer: Diese Nachricht stammt aus einem Google Account. >>>>> Ihre >>>>> Antwort wird in der Google Cloud Gespeichert und durch Google >>>>> Algorythmen zwecks werbeanaöysen gescannt. Es ist derzeit nicht >>>>> auszuschließen das ihre Nachricht auch durch einen NSA >>>>> Mitarbeiter >>>>> geprüft wird. Durch kommunikation mit diesen Account stimmen >>>>> Sie >>>>> zu das >>>>> ihre Mail, ihre Kontaktdaten und die Termine die Sie mit mir >>>>> vereinbaren >>>>> online zu Google konditionen in der Googlecloud gespeichert >>>>> wird. >>>>> Sollten sie dies nicht wünschen kontaktieren sie mich bitte >>>>> Umgehend um >>>>> z.B. alternativen zu verhandeln. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> SailfishOS.org Devel mailing list >>>>> To unsubscribe, please send a mail to >>>>> devel-unsubscr...@lists.sailfishos.org >>>>> <mailto:devel-unsubscr...@lists.sailfishos.org> >>>>> >>>>> _______________________________________________ >>>>> SailfishOS.org Devel mailing list >>>>> To unsubscribe, please send a mail to >>>>> devel-unsubscr...@lists.sailfishos.org >>>>> <mailto:devel-unsubscr...@lists.sailfishos.org> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> SailfishOS.org Devel mailing list >>>>> To unsubscribe, please send a mail to >>>>> devel-unsubscr...@lists.sailfishos.org >>>>> >>>>> _______________________________________________ >>>> SailfishOS.org Devel mailing list >>>> To unsubscribe, please send a mail to >>>> devel-unsubscr...@lists.sailfishos.org >>>> >>> >>> >>> _______________________________________________ >>> SailfishOS.org Devel mailing list >>> To unsubscribe, please send a mail to >>> devel-unsubscr...@lists.sailfishos.org >>> >> >> _______________________________________________ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to >> devel-unsubscr...@lists.sailfishos.org > > -- > > Disclaimer: Diese Nachricht stammt aus einem Google Account. Ihre Antwort > wird in der Google Cloud Gespeichert und durch Google Algorythmen zwecks > werbeanaöysen gescannt. Es ist derzeit nicht auszuschließen das ihre > Nachricht auch durch einen NSA Mitarbeiter geprüft wird. Durch > kommunikation mit diesen Account stimmen Sie zu das ihre Mail, ihre > Kontaktdaten und die Termine die Sie mit mir vereinbaren online zu Google > konditionen in der Googlecloud gespeichert wird. Sollten sie dies nicht > wünschen kontaktieren sie mich bitte Umgehend um z.B. alternativen zu > verhandeln. > > _______________________________________________ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org >
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
