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?
> 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. ;-)
> Advantages of Tracker:
>
> supports potential future use cases (combining data from different
> categories, partial reading/writing, fine-grained annotations on data
> origin)
This will become very useful when implementation communication history.
For Maemo5 we used a detached, custom sqlite database for storing
communication history. Bringing pieces together, keeping them in sync,
avoiding problems from concurrent access, getting reasonable response
times and memory consumptions where a permanent problem with that
solution.
By using tracker as data store, we get the data aggregation for free,
and we have to solve most concurency and performance problems at justone
single place.
Similar things apply for presence information. It might feel strange to
put such information into a data store, but Tracker permits marking RDF
properties as volatile. So presence information should not hit the disk
if desired. Reminds me I have to push the Tracker guys harder to finally
repair transient property support.
> better searching
> scalability (?)
When aggregating information from multiple, independent, incompatible
databases you'll face several scalability problems:
1. You get the I/O overhead for multiple databases
2. You get concurency management overhead for multiple databases
3. Most importantly you get quite some memory overhead, since most
likely eachapplication interested in that data aggregation will have
to keep the aggregated data in memory. Since aggregation takes time,
and dialogs shall be shown within milliseconds, they most probably
will aggregate the data ahead and keep it around during lifetime.
One might believe only few applications need that aggregated data, but
both in Fremantle and now also in Harmattan we have dozens if not more
applications using a contact picker and therefore using aggregated data.
It was quite a memory usage hazard in Fremantle.
> read performance (?)
Reading performance of both solutions should be compareable for
fetch-all. At this moment tracker should show better reading performance
when using (not so complex) filters, as it stores contacts decomposed.
One can add indexes for vCard attributes to EDS. Together with lazy
vCard parsing in libebook this should give compareable reading
performance.
> Disadvantages of Tracker:
> data protection missing in both EDS and Tracker, but less obvious how
to implement it in Tracker
The solution proposed for EDS is protecting its database files. Same
solution can be applied to tracker. Since you can deal without data
aggregation at this moment, you should not loose anything if we create a
separate Tracker database for contacts and apply same file level
protection as for EDS.
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. Considering privace concerns this is a very
significant feature, which cannot be reasonable implemented with EDS -
AFAIK.
> slow write performance in QtContacts-Tracker (?)
Please give concrete test data. Like Philip Van Hoof demonstrated, it
rather seems writing performance of EDS and Tracker seems to be
comparable - which is not surprising that I/O is the limiting factor.
With Tracker's recent addition of sparql-update (INSERT OR REPLACE
statement) we have seen performance improvments of up to 25%. This would
set QtContactsTracker ahead of EDS. Also note that the filebackend of
EDS doesn't seem to implement vcard attribute indexes yet. Adding them
to EDS to get search performance comparable to Tracker would add another
performance penalty to EDS.
> Plan:
>
> write a QtContacts storage plugin (details on QtContacts-EDS),
> EDS improvements
> Opens:
>
There is a separate wiki page. I'll comment in separate mail.
Ciao,
Mathias
--
Mathias Hasselmann <[email protected]>
http://openismus.com/
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
