[SailfishDevel] Sailfish OS Open Source Community Collaboration Meeting 2nd of June 2016
Andrew Branson
sfdevlist at andrewbranson.net
Thu Jun 2 12:40:08 UTC 2016
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
> <sfdevlist at andrewbranson.net <mailto:sfdevlist at 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.giulietta at gmail.com
> <mailto:users.giulietta at gmail.com>
> <mailto:users.giulietta at gmail.com
> <mailto:users.giulietta at 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
> <leginee at gmail.com <mailto:leginee at gmail.com>
> <mailto:leginee at gmail.com <mailto:leginee at 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.giulietta at gmail.com
> <mailto:users.giulietta at gmail.com>
> <mailto:users.giulietta at gmail.com
> <mailto:users.giulietta at 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.adams at jolla.com
> <mailto:chris.adams at jolla.com> <mailto:chris.adams at jolla.com
> <mailto:chris.adams at 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-bounces at lists.sailfishos.org
> <mailto:devel-bounces at lists.sailfishos.org>
> <mailto:devel-bounces at lists.sailfishos.org
> <mailto:devel-bounces at lists.sailfishos.org>>
> [devel-bounces at lists.sailfishos.org
> <mailto:devel-bounces at lists.sailfishos.org>
> <mailto:devel-bounces at lists.sailfishos.org
> <mailto:devel-bounces at lists.sailfishos.org>>] on behalf
> of James Noori [james.noori at jolla.com
> <mailto:james.noori at jolla.com>
> <mailto:james.noori at jolla.com
> <mailto:james.noori at jolla.com>>]
> *Sent:* Wednesday, June 01, 2016 11:15 PM
> *To:* devel at lists.sailfishos.org
> <mailto:devel at lists.sailfishos.org>
> <mailto:devel at lists.sailfishos.org
> <mailto:devel at 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-unsubscribe at lists.sailfishos.org
> <mailto:devel-unsubscribe at lists.sailfishos.org>
> <mailto:devel-unsubscribe at lists.sailfishos.org
> <mailto:devel-unsubscribe at lists.sailfishos.org>>
>
>
> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscribe at lists.sailfishos.org
> <mailto:devel-unsubscribe at lists.sailfishos.org>
> <mailto:devel-unsubscribe at lists.sailfishos.org
> <mailto:devel-unsubscribe at 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-unsubscribe at lists.sailfishos.org
> <mailto:devel-unsubscribe at lists.sailfishos.org>
> <mailto:devel-unsubscribe at lists.sailfishos.org
> <mailto:devel-unsubscribe at lists.sailfishos.org>>
>
>
> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscribe at lists.sailfishos.org
> <mailto:devel-unsubscribe at lists.sailfishos.org>
> <mailto:devel-unsubscribe at lists.sailfishos.org
> <mailto:devel-unsubscribe at 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-unsubscribe at lists.sailfishos.org
> <mailto:devel-unsubscribe at lists.sailfishos.org>
>
> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscribe at lists.sailfishos.org
> <mailto:devel-unsubscribe at lists.sailfishos.org>
>
>
>
>
> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe at lists.sailfishos.org
>
More information about the Devel
mailing list