[SailfishDevel] Sailfish OS Open Source Community Collaboration Meeting 2nd of June 2016
Tone Kastlunger
users.giulietta at gmail.com
Thu Jun 2 12:34:42 UTC 2016
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>
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>> 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>> 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>> 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>> 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>
>> [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>]
>> *Sent:* Wednesday, June 01, 2016 11:15 PM
>> *To:* 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://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>
>>
>>
>> _______________________________________________
>> 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>
>>
>> --
>>
>> 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>
>>
>> --
>>
>> 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
>>
>> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscribe at lists.sailfishos.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20160602/1c35615a/attachment-0001.html>
More information about the Devel
mailing list