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
