Fake server test : contd

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.

  1. Initial PROPFIND response
  2. OPTIONS response
  3. PROPFIND response for user address set
  4. PUT request and response
  5. 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.

  1. Changes to Organizer’s object resource
  2. Changes to Attendee’s object resource

For organizer’s changes, schedule-tag may or may not be changed on the type of the change.
[Refer http://tools.ietf.org/html/rfc6638#section-3.2.10]

  1. 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[1].
  2. 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.

  1. [1]Schedule-tag should be changed after processing updates from the organizer which contains updates more than other attendees’ PARTSTAT changes.
  2. Schedule-tag should not be changed after processing updates from organizer which only contains PARTSTAT changes of other attendees[2].
  3. 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. [2]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.

  1. change the existing calendar item(date/time, summary)
  2. send the changed item to the calendar by cal.modifyItem(Item,oldItem,listener)
  3. merge the change with attendee object resource and update the schedule-tag after PUT request
  4. reply to the multistatus message with new schedule-tag
  5. assert client’s item and servers item to make sure both are similar


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.