On Fri, 2011-04-01 at 21:21 +0300, Jens Georg wrote: > > > 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 > > > > I'd like to clarify something from the page: > > > > Maemo solution: QtContacts (API) + QtContacts-Tracker (glue code) + > > Could we stop calling it "glue code"? It's about as much glue code as > the folks backends.
Sorry - I was quoting the wiki page. I didn't intend to diminish qtcontacts-tracker. > > folks-telepathy <-> Telepathy > > folks-tracker <-> Tracker > > folks-libsocialweb <-> Libsocialweb > > ... > > Out of interest - since I've not really actively following the folks > development - does the aggregation happen completely in memory? So each > application who wants to do aggregating has to do it on its own all over > again? I'm thinking of the memory implications here ... Right. We've got plans to add lazy-loading for contact attributes and search-based retrieval to significantly reduce the overhead here. It hadn't been necessary until this point. Regards, -Travis _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
