[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 II.

Date: Thu, 17 Jan 2002 13:04:03 -0500
To: "ietf-calendar@xxxxxxx" <ietf-calendar@xxxxxxx>
From: Mark Paterson <markp@xxxxxxxxxxx>
Subject: Re: Synchronization [Was: Re: CAP: Last Call By March IETF: Need  Volunteers!]

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 doc.
> > >
> > > It is. I think it does meet the synchronization requirements.
> > > And we limited synchronization to a bare minimum. That is
> > > that you must be able to upload and download an entire calendar
> > > and what ever it takes to make two calendars look the same.
> >
> >   Have we gone through the exercise of making sure that we
> > support synchronization? If we limit support to a bare minimum
> > can it hurt performance of synchronization?
> >
> >   A CUA is able to query on the last modified LAST-MODIFIED
> > property to find all the components that have changed the last
> > time a sync was done. Using the METHOD:DELETE it can find all
> > components that have been deleted. Is this sufficient?
> >
> >   Should we add a small section or sub-section on CAP
> > 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 issue.

I think there are a few issues to consider before closing this.

The key paragraph from the CAP Requirements document is as follows:

"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 questions.

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?


George

--
Mark Paterson
Director, Client R&D
Steltor
mailto:markp@xxxxxxxxxxx
http://www.steltor.com


--
Mark Paterson
Director, Client R&D
Steltor
mailto:markp@xxxxxxxxxxx
http://www.steltor.com