The Synchronization Engine

NOTE: Some of the description below may not apply to all versions - this is a work in progress.

The synchronization engine (SE) is an outboard process which handles external subscriptions and synchronizes them with a copy stored in the calendar system. Currently it only handles inbound subscriptions, that is it will mirror an external calendar inside bedework.

The SE communicates with the calendar system using a small extension to CalWS-SOAP which provides some extra operations to handle the creation and update of subscriptions. The SE is capable of synchronizing between any 2 sytems that provide the required support.

Mode of operation

The SE maintains a queue of subscriptions which it processes periodically according to the refresh interval defined per subscription. Handling a single subscription may involve a single update if push updates are enabled (not fully implemented) or a periodic refresh otherwise.

Periodic Refresh

The remote resource is usually specified as a calendar resource, e.g. an ics file. The SE does a GET on that resource supplying an etag. If the resource has not chnaged it should respond with a no-content sttaus and the subscription will be re-queued. If the resource has changed it will be read and parsed into the individual items. These items will be processed in batches and the following takes place:

1. Each item in the batch - event or task - is run through input filters which may remove properties or components, for example alarms and dtstamps.
2. A request is sent to the target requesting the UID and lastmod, if we trust lastmods, or the entire item if we don't.
3. If we have to add a new event/task it is run through output filters for the target and stored. These may add categories, remove properties etc.
4. If we trust lastmods we compare them. If the incoming event was updated we fetch the target. The target is run through input filters and then compared with the incoming item. See below fo notes on comparing.
5. If the item has changed the comparison resulted in a set of CalWS-SOAP update operations which we apply to the target. Note: we don't do a full replacement - we actually are applying updates only to the changed fields.

After processing the current etag is stored in the subscription and it is re-queued.

The comparison process.

This is carried out on an xCal version of the incoming and target items. The comparison will skip elements of the items based on a ski list which may specify components, e.g. alarms, properties, e.g. create date and parameters , e.g. partstat. This skip list is supplied by the output filters.

Public v personal

The synch engine was built to satisfy the needs of personal calendaring where it was felt that having a copy of an external calendar was important, especially if it might affect free busy or personal schedules. The SE is being extended to the public side which presents more problems . In particular the curated nature of public events means that categories must be provided and we need to be careful not to introduce unwanted data - for example - badly specified locations. This was the driver behind the implementation of filters to allow significant modifications to be applied to events as they are stored in the system.