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?

> > 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.


-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Reply via email to