Calendar:ITIP and iMIP Support: Difference between revisions

Jump to navigation Jump to search

Calendar:ITIP and iMIP Support (view source)

Revision as of 09:28, 13 July 2007

145 bytes added ,  13 July 2007
no edit summary
No edit summary
Line 1: Line 1:
== Meeting Scheduling in Lightning Proposal (iMip and iTip support) ==
== Meeting Scheduling in Lightning Proposal (iMip and iTip support) ==
[[Calendar:Feature Implementations:iTIP-iMIP:Current iTIP Design|Current iTIP-iMIP design]]


A common problem among users of any calendaring software is scheduling shared events, or meetings between people. In general, there should be a natural method to schedule these events that works well within the current paradigms of the software. The RFC specifications for [http://www.ietf.org/rfc/rfc2446.txt iMIP] and [http://www.ietf.org/rfc/rfc2447.txt iTIP] address this. This document will confine itself to our proposed implementation, for questions about the specifications, please refer to these RFC's.  Also, there are various diagrams throughout, and in those diagrams, Thunderbird components appear in blue while  Lightning components (either existing or proposed) appear in yellow. However, this distinction has nothing to do with which components need to be extended in order to fully support iTIP and iMIP.
A common problem among users of any calendaring software is scheduling shared events, or meetings between people. In general, there should be a natural method to schedule these events that works well within the current paradigms of the software. The RFC specifications for [http://www.ietf.org/rfc/rfc2446.txt iMIP] and [http://www.ietf.org/rfc/rfc2447.txt iTIP] address this. This document will confine itself to our proposed implementation, for questions about the specifications, please refer to these RFC's.  Also, there are various diagrams throughout, and in those diagrams, Thunderbird components appear in blue while  Lightning components (either existing or proposed) appear in yellow. However, this distinction has nothing to do with which components need to be extended in order to fully support iTIP and iMIP.
Line 15: Line 17:
=== Handling Phase ===
=== Handling Phase ===


The handling phase is instigated by the user interacting with the active content that is generated by the presentation phase. In the current implementation, this means that the user clicked the “Accept�? button. Once this happens, it is translated to a moz-cal-handle-itip:/// URI, which is handled by the registered protocol handler in calItipProtocolHandler. The protocol handler is responsible for parsing the URI (which encapsulates the VCALENDAR data) and in our current implementation, adds the VCALENDAR item to the first calendar in the calICalendarManager's list of calendars.
The handling phase is instigated by the user interacting with the active content that is generated by the presentation phase. In the current implementation, this means that the user clicked the “Accept�? button. Once this happens, it is translated to a moz-cal-handle-itip:/// URI, which is handled by the registered protocol handler in calItipProtocolHandler. The protocol handler is responsible for parsing the URI (which encapsulates the VCALENDAR data) and in our current implementation, adds the VCALENDAR item to the first calendar in the calICalendarManager's list of calendars.


  '''Note:''' In order to see this for yourself in Lightning, you will need a
  '''Note:''' In order to see this for yourself in Lightning, you will need a
Line 66: Line 68:
Once the item is presented to the user, and the user makes their decision on how to respond to the item, it falls to the iTIP handler to ensure that the proper action is taken, and that the proper responses are generated. While it may be redundant to have an iTIP protocol handler when the XUL presentation layer will have all the necessary information to complete the iTIP response, it maximizes our extensibility. Encapsulating this logic in a non-GUI iTIP protocol handler permits us to automate any portion of the iTIP handling. For instance, most users would probably prefer the application automatically either respond to or decline Free/Busy requests.  
Once the item is presented to the user, and the user makes their decision on how to respond to the item, it falls to the iTIP handler to ensure that the proper action is taken, and that the proper responses are generated. While it may be redundant to have an iTIP protocol handler when the XUL presentation layer will have all the necessary information to complete the iTIP response, it maximizes our extensibility. Encapsulating this logic in a non-GUI iTIP protocol handler permits us to automate any portion of the iTIP handling. For instance, most users would probably prefer the application automatically either respond to or decline Free/Busy requests.  


A “moz-cal-handle-itip:///�? URI is generated that encapsulates the following items:<br><br>
A “moz-cal-handle-itip:///�? URI is generated that encapsulates the following items:<br><br>
  1. The calendar Data (which is still escaped–the protocol handler will
  1. The calendar Data (which is still escaped–the protocol handler will
     be responsible for unescaping it.)
     be responsible for unescaping it.)
Line 73: Line 75:
     the Organizer.
     the Organizer.


Currently, the moz-cal-handle-itip URI is generated via an HTML Form submit action. We may choose to move away from this model and create our own internal moz-cal-handle-itip URI handler. This would mean that the iTIP URI would be handled natively by the mozilla system in much the same way that a “chrome�? URI is handled. This iTIP URI Handler XPCOM component would be a thin layer and would pass the URI directly to the underlying calITipProtocolHandler subsystem.  If we decide to make the iTIP URI into a natively supported URI then we would remove the HTML-ness from the current URI specification, removing the &'s and the ?'s. We could also provide a parser directly,and the calITipProtocol handler would not need to parse the URI itself. Additionally, a native iTIP URI handler is also attractive because it could be used by the XUL iMIP presentation layer thus encapsulating the iTIP protocol's complexity.
Currently, the moz-cal-handle-itip URI is generated via an HTML Form submit action. We may choose to move away from this model and create our own internal moz-cal-handle-itip URI handler. This would mean that the iTIP URI would be handled natively by the mozilla system in much the same way that a “chrome�? URI is handled. This iTIP URI Handler XPCOM component would be a thin layer and would pass the URI directly to the underlying calITipProtocolHandler subsystem.  If we decide to make the iTIP URI into a natively supported URI then we would remove the HTML-ness from the current URI specification, removing the &'s and the ?'s. We could also provide a parser directly,and the calITipProtocol handler would not need to parse the URI itself. Additionally, a native iTIP URI handler is also attractive because it could be used by the XUL iMIP presentation layer thus encapsulating the iTIP protocol's complexity.


A typical URI will look like a standard HTML encoded form URI, for example:<br>
A typical URI will look like a standard HTML encoded form URI, for example:<br>
Line 80: Line 82:
The iTIP handler will be able to distinguish between a new event or an update to a previous event based on the rules specified in the iTIP RFC. It will be responsible for notifying the user if there is an error.  
The iTIP handler will be able to distinguish between a new event or an update to a previous event based on the rules specified in the iTIP RFC. It will be responsible for notifying the user if there is an error.  


Furthermore, if the autoResponse field is “false�?, then the iTIPProtocol handler will instantiate a compose window containing the proper iTIP response item, and pre-populating the “TO�? field with proper person.  The user will be allowed to edit the email message before it is sent. If the autoResponse field is “true�? then the email will be formulated and sent automatically, and the user will not be given the opportunity to edit the message. If the user decides not to send a response to the iTIP message, then the autoResponse field will be “no�?. Note that these three strings are NOT localizable and this URI should NEVER be displayed to the user.
Furthermore, if the autoResponse field is “false�?, then the iTIPProtocol handler will instantiate a compose window containing the proper iTIP response item, and pre-populating the “TO�? field with proper person.  The user will be allowed to edit the email message before it is sent. If the autoResponse field is “true�? then the email will be formulated and sent automatically, and the user will not be given the opportunity to edit the message. If the user decides not to send a response to the iTIP message, then the autoResponse field will be “no�?. Note that these three strings are NOT localizable and this URI should NEVER be displayed to the user.


Much of the code for generating a text/calendar encoded email on the fly still lives in the Sunbird codebase file calendarMail.js, and this functionality could be extracted and used by the iTIP protocol handler, or perhaps from an iTIP protocol handling object (if needed).
Much of the code for generating a text/calendar encoded email on the fly still lives in the Sunbird codebase file calendarMail.js, and this functionality could be extracted and used by the iTIP protocol handler, or perhaps from an iTIP protocol handling object (if needed).
Line 151: Line 153:


Please add your comments either here or on the discussion page.
Please add your comments either here or on the discussion page.
[[category:calendar|iTIP and iMIP Support]]
Pluk77
132

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/62095"

Navigation menu