The save_schedules static capability implies that the calendar server (associated with the backend) handles sending requests/updates to other recipients of the item, during create/modify/delete operations.
Evolution would not issue a send_object call in such cases if it senses the capability. Cheers, harish On Tue, 2005-05-24 at 13:45 +0800, Harry Lu wrote: > Harish, JP and Rodrigo, > I am working on evolution-jescs (hydrogen) these days and have a > question. What does CAL_STATIC_CAPABILITY_SAVE_SCHEDULES mean? The usage > in Evolution confuses me. > > For example, the evolution-jescs backend has this capability. When I > create a meeting from Evolution and save it, in save_comp_with_send () > of comp-editor.c, Evolution calls send_component_dialog() to see if it > need to send the component through itip. For hydrogen, > send_component_dialog() return FALSE, so Evolution won't send the > request. However, when I delete this meeting, in delete_event() of > e-calendar-view.c, Evolution calls cancel_component_dialog() to see if > it need to send out the cancel mail. But cancel_component_dialog() for > hydrogen return TRUE, so Evolution will send out the mail. > > In my understanding, for hydrogen, Evolution should not send out > mail in either cases since calendar server will take care of it. So I > think we need to change cancel_component_dialog() to return FALSE for > hydrogen, too. > And in itip_send_comp() of itip-utils.c, there is also a check for > this capability. I think we should just return if the backend has this > capability. > What do you think? > > Thanks! > Harry Lu > > > _______________________________________________ > evolution-hackers maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/evolution-hackers _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
