Re: CAP requirements draft resubmitted

[Mark Paterson <markp@xxxxxxxxxxx>]

At 10:37 AM 11/30/2000 -0500, John Stracke wrote:
> Mark Paterson wrote:
>
> > In the case you describe most sync tools first establish at the beginning
> > of the session whether the client and server are on the same page (i.e. Do
> > they both think they are at the same point as the last time they talked?).
> > This usually done with some form of reference that is stored on both sides
> > so that it can be compared the next time.
>
> This isn't going to scale very well; you don't want any long-term per-client
> state stored on the server, and you don't want to have to confront the
> question of how to identify a particular client.  Unless you can explain why
> the stateless approach won't work, I would be opposed to any such extension.

Extension to what? I didn't ask for any extension. You proposed an example 
where by your Palm gets wiped and as a result isn't in the state it was 
when you actually last sync'ed. I simply tried to explain how most sync 
engines handle this. Keeping track of a sync reference (or anchor) is the 
responsibility of the sync client and the sync engine (or sync server). It 
has nothing to do with the calendar server nor any other back end data 
store containing some data type you may wish to sync (email, contacts, 
MP3s, etc).


> --
> /===============================================================\
> |John Stracke    | http://www.ecal.com |My opinions are my own. |
> |Chief Scientist |==============================================|
> |eCal Corp.      |Q: What goes "Pieces of 7! Pieces of 7!"? A: A|
> |francis@xxxxxxxx|parroty error.                                |
> \===============================================================/

--
Mark Paterson (markp@xxxxxx)
Director, Client Development, CS&T - Lexacom