The error raised in the PROPFIND block could fixed with the help of Philipp. It was due to wrong sequence of initialization messages to the calendar. To initialize a CalDav calendar properly, a sequence of asynchronous messages need to be sent.
- Initial PROPFIND response
- OPTIONS response
- PROPFIND response for user address set
- PUT request and response
- REPORT response
After properly sending messages, the calendar could initialized with items. Added responses and configurations in js objects, so server configurations can be changed easily.
github link for the test :
After the initialization of the calendar properly, I’m moving on with adding schedule-tag and if-schedule-tag-match test cases to the code.
Schedule-tag changes are evaluated on 2 scenarios.
- Changes to Organizer’s object resource
- Changes to Attendee’s object resource
For organizer’s changes, schedule-tag may or may not be changed on the type of the change.
- If the organizer changes the ical object with a PUT request, schedule-tag of the organizer’s object should be changed and changes should be merged with attendee objects.
- Schedule tag will not be changed as a result of processing an attendee PARTSTAT change response.
For attendee object resources there are three cases affect to the schedule tag.
- Schedule-tag should be changed after processing updates from the organizer which contains updates more than other attendees’ PARTSTAT changes.
- Schedule-tag should not be changed after processing updates from organizer which only contains PARTSTAT changes of other attendees.
- Schedule-tag should be changed after processing HTTP requests like PUT,COPY,MOVE from the attendee himself.
It took me sometime to understand the scenario from the server perspective. I’m not sure is it jumping into a prejudgement by understanding that, according to 2nd case about attendee’s schedule-tag change, server leaves attendees outdated by not letting clients updated after processing changes from other attendees.
On the implementation, I’m implementing the organizer scenario first with changes to the object resource. Implementation goes like following.
- change the existing calendar item(date/time, summary)
- send the changed item to the calendar by cal.modifyItem(Item,oldItem,listener)
- merge the change with attendee object resource and update the schedule-tag after PUT request
- reply to the multistatus message with new schedule-tag
- assert client’s item and servers item to make sure both are similar