Subject: RE: CAP requirements draft resubmitted

From: [email-masked]
Date: Tue, 21 Nov 2000 08:06:05 -0500

Pat,
 
Renewing CAP requirements is good thing. It will help to keep us on track.
 
Regarding syncronization, in this age of mobile users with multiple handheld
devices, we need to
ensure that calendar stores can be performed efficiently with the basic
commands of the protocol.
I am of the opinion that syncronization capabilities are fundamental to
ensure acceptance of
CAP as a protocol. I think that we have all the basic contructs in the
protocol to do it. 
 
My vote is "YES" lets keep it in and lets make sure we have all the pieces
to allow for instance
a SyncML client to be properly layed on top of CAP. It should not take too
much time.
 
Comments?
 
Andre Courtemanche
CEO, Steltor.
Formerly known as CS&T/Lexacom.

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 17, 2000 4:45 PM
To: [email-masked]
Subject: CAP requirements draft resubmitted

I resubmitted the CAP requirements draft today.  It expired and I submitted
it for reinstatement since we are still working on CAP.  We may need to make
more adjustments, but I wanted the draft there so we can make more
modifications.  In particular, the requirements state several items about
synchronizing calendars. However, as CAP stands today (in the draft) we
don't have this included.  So, the question is - do we keep it in the
requirements? If so, do we add it into CAP? Thoughts from the list. 

Also, there have been several items on the list regarding restriction
tables.  Unless we hear otherwise from people on the list, we will assume
they look ok.    
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

---

From: Mark Paterson <[email-masked]>
Date: Wed, 29 Nov 2000 09:20:53 -0500

With respect to Synchronization the basic requirement that a sync engine
would require from a CAP compliant server would be an easy way of
requesting changes based on a sync context.

In your typical sync session the device provides all its changes (new
events/tasks, changed events/tasks, and deleted events/tasks) since the
last time it sync'd up and then all the changes from the server are
gathered. They are compared, conflicts resolved, etc.. and then the sync
engine instructs the server as to the changes it needs to make and
instructs the device on the changes it should make. Along the way mapping
information so that device IDs can be properly mapped to server IDs is
updated as well.

It is important to note however that when changes are gathered from a
server that the changes required are not necessarily the changes since
the last time the user sync'd but rather since the last time the user
sync'd with the device in question. A user could have a PDA with a fairly
sophisticated calendar client on it as well as a smart phone with a
simpler calendar on it both of which he or she syncs regularly. If a sync
is first done with the PDA and then with the Phone it is important that
the changes used when syncing the phone are the changes from the last
time user sync'd the phone and not simple since the last time he sync'd.
Thus the need for some sort of sync context when requesting
changes.

If CAP could provide an easy way of gathering such changes a sync engine
claiming proper calendar synchronization based on iCalendar could be
implemented such that it would work with any CAP back end. Combine this
with SyncML and it can be implemented to work with any SyncML compliant
front end. Both ends covered, not bad :)

In other words, "YES". Requirements for sync should definitely
be addressed in CAP.

At 08:06 AM 11/21/2000 -0500, [email-masked] wrote:

Pat,

Renewing CAP requirements is
good thing. It will help to keep us on track.

Regarding syncronization, in
this age of mobile users with multiple handheld devices, we need
to

ensure that calendar stores can
be performed efficiently with the basic commands of the
protocol.

I am of the opinion that
syncronization capabilities are fundamental to ensure acceptance
of

CAP as a protocol. I think that
we have all the basic contructs in the protocol to do it.

My vote is "YES" lets
keep it in and lets make sure we have all the pieces to allow for
instance

a SyncML client to be properly
layed on top of CAP. It should not take too much time.

Comments?

Andre Courtemanche

CEO, Steltor.

Formerly known as
CS&T/Lexacom.

-----Original Message-----

From: [email-masked]
[mailto:[email-masked]]

I resubmitted the CAP requirements draft today.  It expired and
I submitted it for reinstatement since we are still working on CAP.
We may need to make more adjustments, but I wanted the draft there so we
can make more modifications.  In particular, the requirements state
several items about synchronizing calendars. However, as CAP stands today
(in the draft) we don't have this included.  So, the question is -
do we keep it in the requirements? If so, do we add it into CAP? Thoughts
from the list.

Also, there have been several items on the list regarding restriction
tables.  Unless we hear otherwise from people on the list, we will
assume they look ok.

___________________

Patricia Egen Consulting

www.egenconsulting.com

423-875-2652

--

Mark Paterson ([email-masked])

Director, Client Development, Steltor (formerly CS&T -
Lexacom)

---

From: Federico Mena Quintero <[email-masked]>
Date: Wed, 29 Nov 2000 11:00:37 -0600

> Thus the need for some sort of sync context when requesting 

Evolution handles this by having its calendar backend store a log of
modifications to a particular calendar.  The log looks more or less
like

	UID	action		timestamp

	foo	updated		<blah>
	bar	removed		<blah>
	baz	removed		<blah>
	qux	updated		<blah>

When you access a calendar backend, you can ask it for the log's
entries between two particular timestamps.  Synchronization conduits
(e.g. for the Palm Pilot or phones or whatever) can use this
information to figure out what to do.  Each conduit stores the last
timestamp at which it did a sync operation; the next time it runs it
just uses that to query the calendar backend.

If you have the Evolution source tree, you can see the interfaces for
this in evolution/calendar/idl/evolution-calendar.idl.  Look for the
Cal::getChangedUIDs() method.

  Federico

---

From: John Stracke <[email-masked]>
Date: Wed, 29 Nov 2000 11:49:38 -0500

Mark Paterson wrote:

> If a sync is first done with the PDA and then with the Phone it
> is important that the changes used when syncing the phone are
> the changes from the last time user sync'd the phone and not
> simple since the last time he sync'd. Thus the need for some
> sort of sync context when requesting changes.

I would turn it around: because there may be many devices trying
to sync, there should be no server-side context; the awareness of
when the sync was last done should live in the device.

Also, consider this sequence:

  1. I sync my Pilot with my CS.
  2. I back up my Pilot to my desktop.
  3. I sync my Pilot with my CS.
  4. My Pilot's battery goes dead and it loses its data, because
     Palm is too cheap to use flash memory.  (Sorry, this is a
     sore point for me.  :-)
  5. I restore my Pilot from backup.
  6. I sync my Pilot with my CS.

If the CS stores the knowledge that I last synched at #3, then
it's not going to send me the changes that occurred between #1
and #3.  If that knowledge is stored in the Pilot, then it gets
backed up at #2 and restored at #6, and the sync at #7 will get
the right data.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Vote for Ron, and nobody gets hurt! --actual |
[email-masked]|campaign poster from Chicago                 |
\==============================================================/

---

From: Colin DuPlantis <[email-masked]>
Date: Wed, 29 Nov 2000 10:10:36 -0800

Mark Paterson wrote:
<snip>
> sync'd with the device in question. A user could have a PDA with a
> fairly sophisticated calendar client on it as well as a smart phone
> with a simpler calendar on it both of which he or she syncs regularly.
> If a sync is first done with the PDA and then with the Phone it is
> important that the changes used when syncing the phone are the changes
> from the last time user sync'd the phone and not simple since the last
> time he sync'd. Thus the need for some sort of sync context when
> requesting changes.
<snip>

InSchedule
(http://www.criticalpath.net/products/insch_cal_overview.html) handles
synchronization by allowing the sync client to ask for events added or
changed since a certain date.  The sync client can also ask the server
what time the server thinks it is, which the client can store for the
next session.  In other words, we require the sync client to keep track
of the last time it sunk, and supply that time the next time a sync is
requested, if a net change sync is desired.  This prevents the server
from having to know which sync client is attempting to sync, but it does
require the sync client to keep the timestamp from the last sync.

- C

-- 
Colin DuPlantis
Engineering Manager - Calendar
Critical Path, Inc.
http://www.criticalpath.net
320 First Street
San Francisco, CA 94105
Direct: 415.808.8816
Main: 415.808.8800
Fax: 415.808.8778

---

From: Mark Paterson <[email-masked]>
Date: Wed, 29 Nov 2000 15:20:46 -0500

Your're quite right but I wasn't trying to get into all the semantics 
involved with a sync but rather simply point out that knowing what has 
changed is crucial to a sync and CAP should not preclude the ability to 
gather such changes (nor am I implying that it does but just that in 
reviewing it considering things from a sync perspective will be important).

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. If they don't match (which would 
occur in your example) then the engine has the more daunting task of trying 
to figure out who's where and wouldn't request changes in this manner 
(sometimes called a "slow sync").

--
Mark Paterson ([email-masked])
Director, Client Development, Steltor (formerly CS&T - Lexacom)

---

From: Mark Paterson <[email-masked]>
Date: Wed, 29 Nov 2000 15:48:40 -0500

Hi Colin,

What you describe would certainly take care of things. The timestamp is 
part of the context information required for the sync. And you are right 
the client does need to save this. I did not mean to imply that the server 
was required to save some new-fangled "sync context" but in reviewing the 
way I worded things perhaps that's how it came across. I meant only to 
point out that being able to gather changes is important and to further 
point out that it is not as easy as knowing what has changed since the last 
time.

I was actually trying to avoid implying any form of implementation and to 
just provide enough information to justify why I would answer "YES" to 
Pat's question from her message (Cut and paste below)

"In particular, the requirements state several items about synchronizing 
calendars. However, as CAP stands today (in the draft) we don't have this 
included. So, the question is - do we keep it in the requirements? If so, 
do we add it into CAP?"

Mark Paterson

---

From: John Stracke <[email-masked]>
Date: Thu, 30 Nov 2000 10:35:27 -0500

Mark Paterson wrote:

> I meant only to

I still don't understand this part--to me, it seems that knowing what has
changed should be enough.  Could you explain, please?

--
/===============================================================\
|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|
[email-masked]|parroty error.                                |
\===============================================================/

---

From: John Stracke <[email-masked]>
Date: Thu, 30 Nov 2000 10:37:52 -0500

Mark Paterson wrote:

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

---

From: Mark Paterson <[email-masked]>
Date: Thu, 30 Nov 2000 11:11:52 -0500

>changed should be enough.  Could you explain, please?

Knowing what has changed since the last time the user sync'd his server 
with a particular device IS enough but simply knowing what has changed 
since the last time you asked for changes is not, hence the need for a 
mechanism such as Colin mentioned where by you can request changes based on 
a timestamp.

---

From: Mark Paterson <[email-masked]>
Date: Thu, 30 Nov 2000 11:29:46 -0500

>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).

--
Mark Paterson ([email-masked])
Director, Client Development, CS&T - Lexacom