[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: Re: Synchronization [Was: Re: CAP: Last Call By March IETF: Need Volunteers!]
For some reason this didn't seem to ever show up on the list. Take
Date: Thu, 17 Jan 2002 13:04:03
To: "ietf-calendar@xxxxxxx" <ietf-calendar@xxxxxxx>
From: Mark Paterson <markp@xxxxxxxxxxx>
Subject: Re: Synchronization [Was: Re: CAP: Last Call By March IETF:
At 02:11 PM 1/16/2002 -0500, George Babics wrote:
Doug Royer wrote:
> > >
> > > > 5) Synchronization:
> > > > -------------------
> > > >
> > > > Investigate if there is enough in CAP to
allow for synchronization?
> > > > I believe this is in the requirements
> > >
> > > It is. I think it does meet the synchronization
> > > And we limited synchronization to a bare minimum. That
> > > that you must be able to upload and download an entire
> > > and what ever it takes to make two calendars look the
> > Have we gone through the exercise of making sure
> > support synchronization? If we limit support to a bare
> > can it hurt performance of synchronization?
> > A CUA is able to query on the last modified
> > property to find all the components that have changed the
> > time a sync was done. Using the METHOD:DELETE it can find
> > components that have been deleted. Is this sufficient?
> > Should we add a small section or sub-section on
> > describing how synchronization can be done?
> I think that we had agreed that this was an implementation
> specific thing for now. At the very least we specified that
> a CUA must be able to upload an entire calendar and do the
> diff work it self.
> No one has opposed a synchronization specification. I say we
> need one - AS A SEPARATE DRAFT. For now a CUA can get it done
> by uploading the entire calendar - or by guessing from any
> VQUERYs it can make.
However, if there is something that we can easily add to
CAP that can help synchronization, we may want to add it. On the
other hand, what I described earlier, on how a CUA can have
basic synchronization, by using query on last modified time
and METHOD:DELETE, should be enough.
Thus, if there are no objections, I will close the
I think there are a few issues to consider before closing this.
The key paragraph from the CAP Requirements document is as
"CAP MUST allow synchronization, meaning at a minimum that the CUA
is able to find and retrieve new, modified or deleted entries for a given
time period. The CUA MUST be able to find out which entries have been
added, modified or deleted since it last synchronized, in order to
operate in disconnected mode. This requirement may be satisfied using the
query requirements already defined."
In other words it must be possible for a sync engine (client, server,
whatever) to be able to get the answers to the following three
1) Within the given date range what entries are new?
2) Within the given date range what entries have changed?
3) Within the given date range what entries have been deleted?
Using a query on last modified time with a date range should allow you to
gain answers to 1) and 2). The sync engine just needs to keep track of
the time stamp from the last time they asked. Most sync solutions today
have a sync context or anchor (or some other fancy name) but when dive in
you'll find they all pretty much are just exactly that, the time stamp
from the last successful sync. The sync engine need merely enumerate
through the results and all the IDs it recognizes are changes and all the
ones it doesn't are new.
The only problem I can foresee has to do with instances of recurring
entries. If I change the time of an instance of a meeting or delete an
instance this will change the recurrence rule for this entry and
consequently the last modified time but if I am doing a query over a
specific time period the first instance of the repeating may not be
in this time period so will I get it? What does DTSTART and DTEND mean in
this case? I think this is a basic problem that the people discussing the
CAP-QL need to address. If I am trying to get all the entries in a week
to populate a week view for example, I need some guarantee that I will
get the entries with recurrence rules that cause instances to fall within
my range. If the CAP-QL addresses this then I guess the issue for sync
will be taken care of as well.
Now we get to question 3). You suggest that we query for the method
DELETE within a date range. Combined with the last modified time I'll get
all the newly marked DELETE entries since the last time I sync'd. This
all seems great but is assumes that all CUAs will use a MODIFY command
with the DELETE method. The problem is that there is also a command
(CANCEL or is it DELETE??) that can wipe out an entry completely. If one
CUA does it one way and another the other then how can the sync engine be
sure that it is really being told about everything that has been deleted?
You don't want the sync engine having to query for ever entry ID it knows
about to see if it still there. Is there some guarantee that CAP
compliant CUAs will use the MODIFY command?
One last issue with deletes has to do with recurring entries. If I delete
an instance then there is now an exception in my rule that would keep an
instance from falling within my interested range. Even if the above
failing of CAP-QL is resolved I may not be able to get this? Is there a
way to query using a range and the last modified time combined with a
search for an EXDATE?
Director, Client R&D
Director, Client R&D