Subject: Alternative CAP Sync Proposal

From: Mark Paterson <[email-masked]>
Date: Fri, 15 Feb 2002 16:00:57 -0500

X. Synchronisation and CAP

The need for data synchronisation exists
today.  Due to the exponential growth of mobile devices and user’s
needs for instant access the potential for “islands of communication”
exists. The continued expansion of data on devices and applications is
accelerating the need for Data Synchronisation to manage these
“islands”.  Recognizing this reality it is important that CAP not
inhibit the ability for data synchronisation solutions to be
implemented.

Synchronisation from the perspective of CAP is seen as…

“the process of exchanging information between multiple physical or
virtual locations for the purpose of ensuring that each location's copy
of that information reflects the same information content”
WAP-234-SYNC-20010207-draft

[Editor’s NOTE: I need to hunt down the exact WAP Spec #]

Based on this perspective it is therefore important that data
synchronisation solutions be able to query a CAP compliant CS for all
changes within a range of time, meaning at a minimum that the CUA is able
to find and retrieve new, modified or deleted entries for a given time
period. This section will attempt through explanation and example to show
that this is possible however it is not meant to be exhaustive. It will
do its best not make any assumptions about how a data synchronisation
solution should work and stick to the topic of querying for
changes.

The most important concept for data synchronisation solutions to
understand is that all objects within a CAP CS have a LAST-MODIFIED
property that is updated whenever the object is changed. By saving the
last time a synchronisation was performed a data synchronisation solution
can use this value in any VQUERY it builds up in comparison with the
LAST-MODIFIED property to determine changes since the last time a
synchronisation was performed.

The example below looks for changes to booked (METHOD = ‘CREATE’) VEVENT
entries that occur within a given range (using DTSTART).

BEGIN:VQUERY

EXPAND:TRUE

QUERY:SELECT * FROM VEVENT WHERE

DTSTART < upper range AND

DTSTART > lower range AND

METHOD = 'CREATE' AND LAST-MODIFIED > last time asked

END:VQUERY

As all booked entries will have a unique UID (as specified in [ICAL]),
data synchronisation solutions that save these UIDs can then process
through the results of the query above and determine all newly booked
entries (those objects returned with UIDs that are not recognized) and
all modified pre-existing booked entries (those objects returned with
UIDs that are recognized). For deleted entries it must be understood that
booked entries will NOT actually be removed but rather will be modified
and marked with METHOD:DELETE so they will be reported as modifications
and can be picked out by looking for METHOD:DELETE.

This simple example would therefore seem to provide data synchronisation
solutions with what they need however there are some limitations that
should be understood.

The above example allows data synchronisation solutions to determine what
has been deleted by recognizing objects with METHOD:DELETE within the
modifications. Although this works nicely for non-recurring booked
entries it will not catch instances of a recurring booked entry that may
no longer exist as the recurrence, upon expansion, will no longer lead to
an instance that falls within the range that the query is covering.
Depending on a data synchronisation solution’s approach therefore it may
be necessary to also query to see if any recurring entry that should have
caused an instance to fall within range in the past has changed and if so
whether this change is actually something that should be considered as a
delete to the data synchronisation solution.

It is also very important to note that the example given above has only
looked for changes to booked entries. It has not taken into consideration
possible unprocessed ITIP objects. Booked entries cannot be considered
up-to-date until all ITIP objects have been processed. If data
synchronisation solutions want to ensure that the booked entries are
completely up-to-date then it must first process the changed non-booked
entries (unprocessed ITIP objects). In such a case data synchronisation
solutions are no different then any other CUA and must process the ITIP
objects as specified in section XX, “XXXXX”.

[Editor’s NOTE: I need put the right section reference]

At a minimum a CUA is able to find and retrieve new, modified or
deleted entries for a given time period therefore data synchronisation
solutions should be possible.

--

Mark Paterson

Director, Client R&D

Steltor

mailto:[email-masked]

http://www.steltor.com

---

From: Doug Royer <[email-masked]>
Date: Fri, 15 Feb 2002 19:58:44 -0700

Mark Paterson wrote:

> changes within a range of time, meaning at a minimum that the CUA is
> able to find and retrieve new, modified or deleted entries for a given
> time period. This section will attempt through explanation and example
> to show that this is possible however it is not meant to be
> exhaustive. It will do its best not make any assumptions about how a
> data synchronisation solution should work and stick to the topic of
> querying for changes.

The text above would have been great for the requirement document,
but not for CAP.

If you are SURE that NO other CUA will access the same calendar,
your proposal is worth considering. But that is just not true in
all cases.

You have to get all BOOKED, iTIP, and DELETE objects in one
query. You have to process any updated BOOKED and DELETE objects
before the iTIP entries. If you don't another CUA could have
changed the state of the objects and you are synching with 
phantom data.

If more that one CUA is going to be doing a sync. You MUST
sync both directions.

This proposal did not have any specific methods that would allow N
number CUAs to all be in sync. (or CUA-bots) It is NOT up to the CUA
to worry about sync. If all CUA do not sync the same way or in the
same order - then you can be chasing updates all day long.

---

From: Mark Paterson <[email-masked]>
Date: Mon, 18 Feb 2002 15:50:59 -0500

At 07:58 PM 2/15/2002 -0700, you wrote:

but not for CAP.

I just wanted to define some context for the section.

If you are SURE that NO other CUA
will access the same calendar,

all cases.

How is a sync CUA different then any other CUA? When they connect to a CS
they will all be faced with unprocessed ITIP objects that should be
processed so that their booked entries can be as up to date as possible.

You have to get all BOOKED, iTIP,
and DELETE objects in one

phantom data.

Huh? It's the reverse. Until the ITIP objects have been processed the
state of the booked objects is out of date. Therefore if a data
synchronisation solution cares it will need to process them just like any
other CUA.

If more that one CUA is going to be
doing a sync. You MUST

sync both directions.

What a data synchronisation solution supports is none of CAP's business.
A one way sync is perfectly valid. Look at Pal's HotSync, it has the
options "Desktop overwrites Palm" and "Palm overwrites
desktop". Both are examples of possible one way syncs. A user may
just want to get his/her new meetings and not want to send back changes
from their device just yet. This means changes on their device won't be
reflected on the CS until they do but that is their choice. When changes
do go from CUA to CS, a sync CUA is no different then any other CUA. It
will add, delete, and change entries the same way. There is no sync
specific issue here.

This proposal did not have any
specific methods that would allow N

number CUAs to all be in sync. (or CUA-bots) It is NOT up to the
CUA

same order - then you can be chasing updates all day
long.

"It is NOT up to the CUA to worry about sync."

If I am writing a CUA that allows me to sync my calendar on my phone with
the backend CAP CS where my calendar resides I some how think my CUA
might want to worry about sync.

"If all CUA do not sync the same way or in the same order - then you
can be chasing updates all day long."

A Sync CUA can sync in any way it wants. What is important is that it
process ITIP objects (if it chooses to do so) the same way just like all
other CAP compliant CUAs. This is not a sync issue.

--

Mark Paterson

Director, Client R&D

Steltor

mailto:[email-masked]

http://www.steltor.com