Re: [Evolution-hackers] EDS improvements for MeeGo



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. 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 Ohly gmx de
> http://www.estamos.de/
>
>
>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]