Lightning implementing RFC6638
This page shows the overview implementation of Bug 100390 for Google Summer of Code 2014.
Contents
Abstract
This page specifies improve Lightning scheduling system by implementing latest CalDav features described in RFC 6638 and writing mozmill tests to cover various invitation scenarios. Also, this project requires identify where Lightning code-base lags behind RFC 6638 and update to newly introduced properties.
The properties which have been identified and selected to be updated are displayed in the table below.
Properties that will be addressed
| ID | Change(Property) | Section in RFC | Comments |
|---|---|---|---|
| 1 | min-date-time | section-2.1 | First defined in the RFC 4791 which describes the earliest date/time value can be in a calendar object resource in a certain calendar collection. |
| 2 | max-date-time | section-2.1 | First defined in the RFC 4791 which describes the latest date/time value can be in a calendar object resource in a certain calendar collection. |
| 3 | max-attendees-per-instance | section-2.1 | First defined in the RFC 4791 which indicates the maximum number of attendees can have for an instance of any calendar object resource |
| 4 | SCHEDULE-FORCE-SEND | section-7.2 | This can be defined on both organizer and attendee to send forced invitations without affecting to the original object resources, whenever the server reluctant to send normal scheduling messages. |
| 5 | Schedule-Tag | section-3.2.10 | Works along with If-Schedule-Tag-Match property when merging changes. |
| 6 | If-Schedule-Tag-Match | section-8.3 | This will replace the HTTP etag based property IF-MATCH. |
| 7 | schedule-default-calendar-URL | section-4.3 | Specifies whether a calendar user has a default calendar collection to save calendar object resources. |
| 8 | Allowed attendee changes | section-3.2.2.1 | Attendees are allowed to do minor changes in attendee object resources. Such as Transparent property. |
| 9 | SCHEDULE-STATUS | section-7.3 | shows the status code of last successful scheduling message. |
TODOs
Each property has to be implemented and tested.
| Item | Priority | Progress | Comments |
|---|---|---|---|
| Writing mozmill test to IMIP bar | In Progress | The test injects a mail containing an invitation to check whether the IMIP bar is loaded and buttons are displayed. Then accept the event and make sure it is added at the correct location in the calendar view. Bug 1010294 | |
| SCHEDULE-STATUS | |||
| Implement min-date-time property | |||
| Implement max-date-time property | |||
| Test for above properties | This will define both properties on a calendar collection and attempts to inject events with the property violated. So the server must reply that the property has been violated. | ||
| Implement max-attendees-per-instance property | |||
| Implement SCHEDULE-FORCE-SEND property | |||
| Test max-attendees-per-instance and SCHEDULE-FORCE-SEND | |||
| Implement Schedule-Tag property | In Progress | Can be tested with available calendar tests. | |
| Implement If-Schedule-Tag-Match property | Can be tested with available calendar tests. | ||
| Implement schedule-default-calendar-URL property | |||
| Implement Allowed attendee changes property | |||
| Test for above two properties. |
Schedule Tag Implementation
Schedule-tag implementation will follow this flow chart.
Only most necessary steps are showed.
| Description | Status | Comments |
|---|---|---|
| Servers MUST automatically resolve conflicts with "inconsequential"changes done to scheduling object resources when the "If-Schedule-Tag-Match" request header is specified. The If-Schedule-Tag-Match request header applies only to the Request-URI, and not to the destination of a COPY or MOVE. | Client must send the Request Header. Needs Implementation | Already implemented in the patch. It check if the schedule-tag value is available on the mItemInfoCache. If it's available it sends If-Schedule-tag-Match |
| A response to any successful GET or PUT request targeting a scheduling object resource MUST include a Schedule-Tag response header with the value set to the same value as the CALDAV:schedule-tag WebDAV property of the resource. | Client must parse the tag & store it | Already Implemented in the patch. |
| |
Lightning does not need to implement | Example |
| Clients SHOULD use the If-Schedule-Tag-Match header on requests that update scheduling object resources, instead of HTTP ETag-based precondition tests (e.g., If-Match). Normal ETag-based precondition tests are used in all other cases, e.g., for synchronization. | Should it send it all the time?[1] | Same as the first case. If present in mItemInfoCache then send the If-Schedule-Tag-Match header. |
| Clients MAY use the If-Schedule-Tag-Match request header to do a PUT request that ensures that "inconsequential" changes on the server do not result in a precondition error. | Client must Handle Error Case where schedule-tag does not match | Example |
| Clients MAY use the If-Schedule-Tag-Match request header to do a DELETE, |
Client must Handle Error Case where schedule-tag does not match | Example |
Testing
Testing will be more general sequence of request/response data inject into calendar. That way we can make sure calendar operations are taking place according to RFCs and reacts to predefined behaviour according to given responses. XPCshell based unit test will provide preloaded response data imitating various CalDav server behaviours.
Unit test will basically create a temporary HTTP server on localhost using httpd.js. Calendar will send sync requests to the server and server will respond to them with different response data. Calendar reactions will be asserted against expected values.
