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> 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>> 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>> 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>> 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>> 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> >> [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>] >> *Sent:* Wednesday, June 01, 2016 11:15 PM >> *To:* 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://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> >> >> >> _______________________________________________ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to >> 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> >> >> -- >> >> 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 >
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
