|
|
| Line 1: |
Line 1: |
| == New iTIP Processor Interface ==
| |
| This is based off of the iTIPResponder Patch in {{bug|334685}}
| |
|
| |
|
| This will be the proposed interface into the iTIP Processor that will handle
| |
| all forms of iTIP action, from replying to an iTIP REQUEST to Rescheduling an invitation (eventually).
| |
|
| |
| The interface is simple. An iTIP invitation is encapsulated as an [http://lxr.mozilla.org/seamonkey/source/calendar/base/public/calIItipItem.idl| ItipItem]. An ItipItem is one or more iCALENDAR (RFC 2445) objects that are the same type with the same iTIP METHOD (such as PUBLISH). We also use the ItipItem to designate the user's preference for handling the item. The user can specify whether or not to allow automatic, preference based handling of an ItipItem. This would occur if the user had set up a preference setting to "Always Add all Publish Events to Calendar X". Or, the user can direct what method they would like to respond to an iTIP invitation. For example, the user may wish to decline an invitation to a meeting. This information is encapsulated into the ItipItem before it is sent to the ItipProcessorService object.
| |
|
| |
| If the ItipItem is not fully specified when it is received by the ItipProcessorService, the ItipProcessorService will use the user's iTIP Preference settings to act on the ItipItem appropriately.
| |
|
| |
| To this end, there are just two interfaces needed into the ItipProcessorService.
| |
| * getItipPreference
| |
| * process
| |
|
| |
| The interface would also define preference constants to refer to specific iTIP preferences (the iTIP Preferences would be repeated for each combination of Method and VComponent (VEVENT, VTODO, etc)):
| |
| * const unsigned long targetCalendar; // Default calendar to add/update/delete to/from. '''lilmatt: should this be AUTF8String instead to handle UIDs?'''
| |
| * const unsigned long defaultResponseMethod; // Default response method for this particular iTIP method and VComponent combination
| |
| * const unsigned long isHandledAutomatically; // Whether or not the ItipProcessorService handles this combination of iTIP method and VComponent combination automatically. '''lilmatt: should this be a boolean rather than a long?'''
| |
| * TODO: Do we need a preference to indicate a default response address to be used? '''lilmatt: Won't it screw up reporting if the attendee address we send the invite to != the address of who reports back whether they're coming or not? I know people sometimes send invites to listservs, which is where this may come more into play.'''
| |
| * TODO: Should there be a way to make one call and get all the preference information (perhaps returned as a comma delimited string) for a particular iTIP method and VComponent combination? '''lilmatt: *-delimited strings suck. Go do _anything_ with the categories preferences to see what I'm talking about. If there's a "one call and you get it all" method, it better return something complex enough to hold the data. In truth, this would be performance optimization we may not really need. How many times will you need to check a particular method/vcomp combo in one sitting?'''
| |
|
| |
|
| |
| TODO: Specify the values for these preferences
| |
|
| |
| ===getItipPreference===
| |
| *Return type: AString
| |
| *Returns the preference that the user asked for
| |
| *Input Paramters: 2
| |
| *Parameter 1: An ItipItem for reference
| |
| *Parameter 2: A constant specifying which preference is being requested.
| |
| *idl: AString getItipPrefernece(in calIItipItem itipItem, in unsigned long preferenceConstant);
| |
|
| |
| ===process===
| |
| *Return type: void
| |
| *Input Parameters: 1
| |
| *Parameter 1: An ItipItem to process
| |
| *idl: void process(in calIItipItem itipItem);
| |
| *This call would process the ItipItem based on the structure it encapsulates.
| |
|
| |
|
| == Timezone Testing == | | == Timezone Testing == |