Re: [Evolution-hackers] New 'eclient' branch in eds
- From: Milan Crha <mcrha redhat com>
- To: evolution-hackers gnome org
- Subject: Re: [Evolution-hackers] New 'eclient' branch in eds
- Date: Tue, 19 Apr 2011 17:00:46 +0200
On Tue, 2011-04-19 at 19:39 +0530, Chenthill Palanisamy wrote:
> I would like you to a incorporate some change to the free/busy api.
> Some servers allow querying free/busy information
> for multiple users at a time and the results appear in a iterative
> fashion. The freebusy information of some
> users are delivered first, while the server keeps fetching other
> user's free/busy information. So if we could have he
> FreeBusy api such as this, we could leverage those features,
>
> ECalClientFreeBusy
> e_cal_client_get_freebusy_object_sync (ECalClient *client, time_t
> start, time_t end, const GSList *users, GCancellable *cancellable,
> GError **error);
> (with a async counter-part)
>
> Signal: freebusy_received (ECalClientFreeBusy *fbobject, const gchar
> *user, GSList *ecalcomps)
>
> The clients could watch for the signal and update the freebusy
> information as and when they receive from eds.
Hi,
one more function would be needed, to tell backend from the client that
it may stop delivering free/busy information and/or focus on a new
query. Otherwise you may get responses really any time, which is not
what you actually want.
It all seems to me like an ECalView for free/busy, rather than anything
doable on the backend client itself.
Remember the factory shares backends between data-book/cal-s. With
views, all known are notified about changes on objects (if they belong
to the view), thus even as a view this will not be that easy on the
server side to do, with some hard management of who (EDataCal) is
looking for what (different users, time interval...).
Bye,
Milan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]