Re: [Evolution-hackers] EDS improvements for MeeGo

[Patrick Ohly <patrick ohly gmx de>]

On Di, 2011-04-05 at 16:26 +0530, Chenthill Palanisamy wrote:
> On Tue, Apr 5, 2011 at 2:51 PM, Patrick Ohly <patrick ohly 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 ohly 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 Ohly gmx de
http://www.estamos.de/