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. 

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...).

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to