[evolution-patches] Re: [Evolution-hackers] What does the cal-backend's CAL_STATIC_CAPABILITY_SAVE_SCHEDULES mean?
- From: Harry Lu <Harry Lu Sun COM>
- To: Harish Krishnaswamy <kharish novell com>
- Cc: evolution-patches <evolution-patches ximian com>
- Subject: [evolution-patches] Re: [Evolution-hackers] What does the cal-backend's CAL_STATIC_CAPABILITY_SAVE_SCHEDULES mean?
- Date: Wed, 25 May 2005 10:51:11 +0800
Harish, JP,
Thanks for the explanation
So I think itip_send_comp() of itip-utils.c should just return TRUE
if the backend has this capability, right? Please review the attached
patch.
Thanks!
Harry
Harish Krishnaswamy wrote:
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 - evolution-hackers lists ximian com
http://lists.ximian.com/mailman/listinfo/evolution-hackers
_______________________________________________
evolution-hackers maillist - evolution-hackers lists ximian com
http://lists.ximian.com/mailman/listinfo/evolution-hackers
|
Index: ChangeLog
===================================================================
RCS file: /cvs/gnome/evolution/calendar/ChangeLog,v
retrieving revision 1.2740
diff -u -r1.2740 ChangeLog
--- ChangeLog 24 May 2005 12:36:03 -0000 1.2740
+++ ChangeLog 25 May 2005 02:47:16 -0000
@@ -1,3 +1,8 @@
+2005-05-25 Harry Lu <harry lu sun com>
+
+ * gui/itip-utils.c: (itip_send_comp): check whether backend could
+ handle sending resuests/updates, and if so, just return.
+
2005-05-24 Chenthill Palanisamy <pchenthill novell com>
Fixes #272114
Index: gui/itip-utils.c
===================================================================
RCS file: /cvs/gnome/evolution/calendar/gui/itip-utils.c,v
retrieving revision 1.98
diff -u -r1.98 itip-utils.c
--- gui/itip-utils.c 15 Mar 2005 16:05:07 -0000 1.98
+++ gui/itip-utils.c 25 May 2005 02:47:17 -0000
@@ -895,11 +895,15 @@
char *ical_string;
CORBA_Environment ev;
gboolean retval = FALSE;
+
+ /* check whether backend could handle sending resuests/updates */
+ if (e_cal_get_save_schedules (client))
+ return TRUE;
CORBA_exception_init (&ev);
/* Give the server a chance to manipulate the comp */
- if (method != E_CAL_COMPONENT_METHOD_PUBLISH && !e_cal_get_save_schedules (client)) {
+ if (method != E_CAL_COMPONENT_METHOD_PUBLISH) {
if (!comp_server_send (method, send_comp, client, zones, &users))
goto cleanup;
}
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]