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 <mailto: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>
<mailto: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>>
<mailto: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>>
<mailto: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>>
<mailto: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>> <mailto: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>>
<mailto: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>>
<mailto: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>>
<mailto: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>>
<mailto: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://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>>
<mailto: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>>
<mailto: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>>
<mailto: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>>
<mailto: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>>
_______________________________________________
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
