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
