Re: [Evolution-hackers] New 'eclient' branch in eds

[Chenthill <pchenthill gmail com>]

On Thu, 2011-04-21 at 08:32 +0200, Milan Crha wrote:
> On Tue, 2011-04-19 at 17:00 +0200, Milan Crha wrote:
> > 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,
> I rethought my thoughts about this and I think I follow your idea more
> closely now. If I try to rephrase it, then it might be:
> 
> On the server side, add new
>    e_data_cal_notify_free_busy_data (..., const GSList *ecalcomps);
> which invokes a signal on the D-Bus connection about (partial) result
> for a free/busy request (note it doesn't provide user separately).
> This signal will be valid only while a get_free_busy request is running.
> Calling e_data_cal_notify_free_busy_data() out of these functions will
> not fail, but the ECalClient consumer may not expect that being done.
> With this limitation we'll have a possibility to cancel pending request,
> if needed. The e_data_cal_respond_get_free_busy() will have no return
> values.
We could term it start_free_busy..

> 
> On the client side, the 'finish' function will be also void and any
> information about free-busy will be available exclusively in a
> "free-busy-received" signal, which will have a parameter GSList
> *ecalcomps.
Once a free_busy_done signal is received, the finish function can be
called. Yup and on the whole I agree to what you have mentioned here.

Thanks, Chenthill.
> 
> I hope we are on the same line now. If you agree, then I'll make a
> change in this way.
> 	Thanks and bye,
> 	Milan
> 
> _______________________________________________
> evolution-hackers mailing list
> evolution-hackers gnome org
> To change your list options or unsubscribe, visit ...
> http://mail.gnome.org/mailman/listinfo/evolution-hackers