On Mon, 04 Apr 2011 10:10:34 +0200, Patrick Ohly wrote:
On Fr, 2011-04-01 at 10:57 +0100, Mathias Hasselmann wrote:
Am Dienstag, den 29.03.2011, 16:35 +0200 schrieb Patrick Ohly:
> Hello!
>
> Let's be more specific about identifying work which needs to be
done.
> I've put together some thoughts here:
> http://wiki.meego.com/Architecture/planning/evolution-data-server
>
http://wiki.meego.com/Architecture/planning/evolution-data-server/QtContacts_storage_plugin
>
http://wiki.meego.com/Architecture/planning/evolution-data-server/eds-improvements
>
Hi Patrick,
Thanks alot for those wiki pages.
Good approach to collect rationales in the public. Will you take
care of
updating the pages, or shall we do this together somehow?
I'll do another pass over the pages today (after catching up with
email), but then they could also be maintained together.
> Contact Storage
>
> Maemo solution: QtContacts (API) + QtContacts-Tracker (glue code)
+
> Tracker (storage)
> EDS: QtContacts (API) + libebook (client side) + EDS (server side,
> storage of vCards in Berkley DB)
Let's start with some nitpicking: Maybe a more neutral term than
"glue
code" can be used for QtContacts-Tracker. ;-)
Yes, see my other email about that - that's an obvious (and easy to
fix)
bug in the Wiki page ;-}
[...]
Thanks for sharing these insights. Good points, and not much that I
can
add to that.
If you look at the future Tracker can provider significantly better
data
protection than EDS. Tracker supports RDF graphs per resource
property
(EDS speak: vCard attribute). Code can be written to restrict access
for
each single graph. Virtual SQLite tables should do the job. If this
should be implemented, you could aggregate information from
different
data sources into one single contact, and still could make sure,
that
for instance only the Addressbook itself can see information
retrieved
from e.g. Facebook.
I'm still not sure how that'll be combined with execution of QSparql
queries inside the application's own process. Once that process gets
read access to the sqlite databases containing the data, it has
access
to all of it. Does "virtual SQLite tables" and "RDF graphs" here mean
that the data would be split into different files?
If the process uses the DBus interface to access Tracker, then the
store
has control on who can query what. Direct access would be reserved for
processes with access to protected data. Note that DBus access is not
that slow, since actual data transfer is done over a UNIX socket.
> slow write performance in QtContacts-Tracker (?)
Please give concrete test data.
I don't have any. That line in the Wiki repeats hearsay, some of it
directly from people who have worked on QtContacts-Tracker, and the
question mark is there because I don't know how relevant that still
is.
I included these rumors in the Wiki because they are TODO items: we
need
data and use cases from the app developers that can be turned into
benchmarks. Then we can remove the question marks.
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
