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 wrote: > > On Di, 2011-04-05 at 13:06 +0530, Chenthill Palanisamy wrote: > >> On Mon, Apr 4, 2011 at 6:24 PM, Patrick Ohly 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
Re: [Evolution-hackers] EDS improvements for MeeGo
On Tue, Apr 5, 2011 at 2:51 PM, Patrick Ohly wrote: > On Di, 2011-04-05 at 13:06 +0530, Chenthill Palanisamy wrote: >> On Mon, Apr 4, 2011 at 6:24 PM, Patrick Ohly 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 5 April 2011 10:21, Patrick Ohly 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 Di, 2011-04-05 at 13:06 +0530, Chenthill Palanisamy wrote: > On Mon, Apr 4, 2011 at 6:24 PM, Patrick Ohly 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
Re: [Evolution-hackers] EDS improvements for MeeGo
On Mon, Apr 4, 2011 at 6:24 PM, Patrick Ohly 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'. 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 ? - Chenthill. > > 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 > ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
