Re: [Evolution-hackers] EDS improvements for MeeGo
On 5 April 2011 10:21, Patrick Ohly patrick.o...@gmx.de wrote: I just noticed that e_book_get_book_view() already has a GList *requested_fields parameter. Is that used and/or implemented anywhere? Not as far as I'm aware, no. Ross ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] EDS improvements for MeeGo
On Tue, Apr 5, 2011 at 2:51 PM, Patrick Ohly patrick.o...@gmx.de wrote: 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 was suggesting to pass the summary-info required for the view as a dbus object (which requires creation of an object similar to CamelMessageInfo) which could save string-vcard convertions and vice-versa in eds and also remove the need for delayed parsing. But as I do not understand the use case, the suggestion may not even be relevant.. 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. Ok this gives me some idea. But, use cases would make things clear. - Chenthill. 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
Re: [Evolution-hackers] EDS improvements for MeeGo
On Di, 2011-04-05 at 16:26 +0530, Chenthill Palanisamy wrote: On Tue, Apr 5, 2011 at 2:51 PM, Patrick Ohly patrick.o...@gmx.de wrote: 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 was suggesting to pass the summary-info required for the view as a dbus object (which requires creation of an object similar to CamelMessageInfo) which could save string-vcard convertions and vice-versa in eds and also remove the need for delayed parsing. That would replace bandwidth-intensive send all data (as it is now) with latency-bound one D-Bus call per item. If enough meta data is sent together with the D-Bus object handle such the actual references to the objects are rarely needed, then this might help. But how would the D-Bus handle be different from reading a single contact via its UID? My feeling is that we are back to list items with UID and REV. 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. Ok this gives me some idea. But, use cases would make things clear. The use case for delayed parsing is the QtContacts layer on top of libebook. All the parsing/encoding would happen there. libebook just needs to pass through vcard strings unmodified. Any parsing of the vCard in libebook is just overhead in this case. -- 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
[Evolution-hackers] EDS improvements for MeeGo
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 The main discussion around this takes place on meego-dev, but it would be good (and probably better) to look into the proposal also here where the upstream EDS developers hang out. Comments and help welcome ;-} -- 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
