On Di, 2011-04-05 at 13:06 +0530, Chenthill Palanisamy wrote: > On Mon, Apr 4, 2011 at 6:24 PM, Patrick Ohly <patrick.o...@gmx.de> wrote: > > Hello! > > > > I have published some more information about our plans for MeeGo: > > http://wiki.meego.com/Architecture/planning/evolution-data-server > > http://wiki.meego.com/Architecture/planning/evolution-data-server/eds-improvements > I was going through the eds-improvements part of it. In the > performance improvement > mentioned at 'Optional parsing of data in the client'. I was wondering > if having a new lib[ecal/ebook] > api that can return two kind of meta data, > + one for populating the view [similar to message-info in mailer] > + for querying the changed information [mentioned at 'change tracking+ > atomic updates' section'.
I don't quite follow. Can you be more specific? I just noticed that e_book_get_book_view() already has a "GList *requested_fields" parameter. Is that used and/or implemented anywhere? The special case relevant for a QtContacts bridge would be to get just the UID. I don't think that this is covered by the current file backend, but at least the libebook/D-Bus/backend API should be in place to implement it. > Thick clients like evolution can still use the existing apis to avoid > much changes unless there is a significant improvement > in performance.. Maybe good to have some profiling data as well ? I have asked my colleagues working on the contacts app in MeeGo about use cases they care for. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers