Re: [Evolution-hackers] EDS improvements for MeeGo
- From: Patrick Ohly <patrick ohly gmx de>
- To: Chenthill Palanisamy <pchenthill gmail com>
- Cc: Evolution Hackers <evolution-hackers gnome org>
- Subject: Re: [Evolution-hackers] EDS improvements for MeeGo
- Date: Tue, 05 Apr 2011 11:21:46 +0200
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 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 Ohly gmx de
http://www.estamos.de/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]