Subject: Re: capreq questions - synchronizing objects vs. changes

From: "Doug Royer [N6AAW]" <[email-masked]>
Date: Sun, 22 Nov 1998 18:10:01 -0800 (PST)

> From: "Mark D. Anderson" <[email-masked]>

> >7. synchronizing objects vs. changes (section 4.5.2)
> >
> >The requirement for CAP is to allow Calendar user agents
> >to be able to identify what has changed on a calendar,
> >that is, components that have been added/deleted/modified.
> >
> >That information about the changed components can then 
> >be used by a CUA (calendar user agent) to synchronize 
> >two calendar stores, resolving conflicts by prompting 
> >the users etc.
> >
> >It is not a requirement for CAP to automatically synchronize
> >two calendar stores.
> 
> There should be some discussion of how an automatic synchronization
> could be done. In the end, for large organizations, an automatic
> scheme is going to be almost mandatory because of the ensuing
> help desk issues otherwise. Also, in many cases the end user isn't
> the one who should be making the decisions about merger anyway,
> because whatever the decision is, it has to result in an eventual
> global consistency, which entails decisions for other stores.
> That is why every large messaging system (Notes, etc.) as well
> as every distributed directory system (X500, LDUP) has mechanisms for
> automatic synchronization with rules/policies that are maintainable by
> an administrator.

If you are talking about replication - we agree. If you want
your palm top device to look like your desktop calendar or
if you want your desktop calendar to look like your palm top calendar.
That's not what is meant by synchronizing in capreq. To make a calendar
look like another calendar, delete the destination calendar, create
the new destination calendar, read all properties and components from
the source calendar and write them to the new destination calendar.

With synchronization:

What if there are appointments that are new to both calendars
since the last synchronization? What if they are for the same time?
Perhaps a manager may decide one time that the secretory is correct.
Example: meet with the CEO vs. take day off.

I was in agreement with you until someone else pointed out that
how the synchronization occurs is a policy issue. Not a protocol issue.
With a CUA implemented as defined in capreq, a CUA (not the protocol)
makes the synchronization decisions (perhaps with or without human input).

> I might note also that IMHO retaining only 
> mod times on components (the only requirement stated) throws
> away too much information to do decent synchronization (that
> is why LDAP and others have a change log).
> 
> -mda
> 

-Doug
-------------------------------------------------------------------
[email-masked]		http://www.royer.com/dougr.html
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: "Mark D. Anderson" <[email-masked]>
Date: Sun, 22 Nov 1998 18:42:20 -0800

>the source calendar and write them to the new destination calendar.

I think there is a 2-by-2 matrix here:
               client-to-server   server-to-server
multi-master
master-slave

I'm not certain which of those 4 entries you want to call "replication"
and which "synchronization". I also don't know which of the 4 you intend
for CAP to provide. Regardless, bulk initialization from scratch
is not acceptable for any of them, IMHO. I'm a little dubious whether
a scheme based only on mod times of wholesale components will be
acceptable for any of them either.

>makes the synchronization decisions (perhaps with or without human input).

It is a protocol issue insofar as you have to have a story for
achieving convergence (i.e. after sufficient time, everyone has the
same info). If there are conflicts, however I choose to resolve
it, the decision must be communicated to other stores. (What happens
the *next* time I synchronize....)

My CUA might implement the resolution automatically or by asking me. But I guess
my preference for those resolution rules wouldn't be part of the calendaring
proposal at this time (i.e. the ACAP of calendars)...

(BTW, note that replication conflicts arise when changes occur
to the *same* objects/attribute at different stores between synchronizations.
It is not obvious that the "meet with the CEO" and "take day off" example
is really in the same category. In a "real" conflict, the CUA would *have*
to choose among changes, because it has only one slot. This example seems
closer to the general case of someone signing me up for something I don't
like, regardless of schedule overlap or not. I guess it comes down to
how strict the integrity rules or business rules or whatever they are called
are supposed to be.)

-mda

---

From: "Doug Royer [N6AAW]" <[email-masked]>
Date: Sun, 22 Nov 1998 19:21:40 -0800 (PST)

>                client-to-server   server-to-server

CAP does not address server-to-server communications so that
leaves 2 entries. If a CUA wishes to synchronize two CS's. It must
have two connections.

If both calendars are on the same CS. I think you are still
going to need two connections.

> for CAP to provide.

For replication: I mean exact copy with one overriding the other in
		 all ways. No human input needed.
		 
For 
		 Some compoents from each calenar may be updated.
		 It is up to the CUA to decide, not the protocol.
		 Human input may be needed.
		 
> Regardless, bulk initialization from scratch  is not acceptable for
> any of them, IMHO. 

Why synchronize if your intend to throw the contents completely away?
If you mean replication, then is it not initialization from scratch?

> I'm a little dubious whether a scheme based only
> on mod times of wholesale components will be acceptable for any of
> them either.

Examples?

> the *next* time I synchronize....)

I would think that using the CAP protocol, you must be able to detect
the conflict (that is in capreq). At that point it's up to the CUA to
decide what the updated component would look like. And there is a
stated need in capreq to update a component. It was felt that
how the CUA makes the decision or automatic rules are not part of CAP
as application and business needs may vary.

There is also no requirement that synchronization itself be successful.
The human or CUA might decide to keep the two calendars different.

> My CUA might implement the resolution automatically or by asking me.
> But I guess my preference for those resolution rules wouldn't be part
> of the calendaring proposal at this time (i.e. the ACAP of calendars)...
> 

Yep.

-Doug

---

From: "Mark D. Anderson" <[email-masked]>
Date: Sun, 22 Nov 1998 20:08:07 -0800

>If you mean replication, then is it not initialization from scratch?

I was objecting to the implied implementation (bulk from scratch),
not to the semantic model, which is correct at least for master-slave replication.

FYI, there is some relevant discussion of this (with examples from mobile
scheduling) at:
http://www.parc.xerox.com/csl/projects/bayou/pubs/sosp-95/www/BayouConflictsSOSP-web_1.html
It suffers from the usual PARC-isms, but is stimulating reading nevertheless.

>> on mod times of wholesale components will be acceptable for any of

My concern has to do with lost information. Under capreq, when I synchronize I would
see the end result of a sequence of changes. I would not see the changes
themselves. Who made the change? Were there multiple changes since my
last sync? Suppose Jack made a substantial change several days ago,
and Mary made a slight change yesterday, and now I sync.

-mda

---

From: "Doug Royer [N6AAW]" <[email-masked]>
Date: Sun, 22 Nov 1998 20:22:34 -0800 (PST)

> and Mary made a slight change yesterday, and now I sync.

iCalendar object do not have properties for who made the last change
or a transaction log.

That could be an additional draft - care to write one :-) ?

-Doug