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 _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers