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
