Re: Version issues

Jim Whitehead (ejw@ics.uci.edu)
Thu, 1 Apr 1999 17:03:57 -0800 

From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 17:03:57 -0800
Message-ID: <004901be7ca4$af71bca0$d115c380@ics.uci.edu>
Subject: Re: Version issues



-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] 
Sent: Friday, March 12, 1999 4:08 AM
To: Chris Kaler (Exchange)
Cc: jamsden@us.ibm.com; gclemm@atria.com; ejw@ics.uci.edu;
dgd@cs.bu.edu; Cragun.Bruce@gw.novell.com;
sridhar.iyengar@mv.unisys.com; ckaler@microsoft.com;
bradley_sergeant@intersolv.com; ABabich@filenet.com
Subject: RE: Version issues










"Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com> on 03/11/99
09:02:18 PM

To:   "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>
cc:   Jim Amsden/Raleigh/IBM, ejw@ics.uci.edu, dgd@cs.bu.edu,
      Cragun.Bruce@gw.novell.com, bradley_sergeant@intersolv.com
Subject:  RE: Version issues





Two things are twice as complicated as one, if one is sufficient
(after all, you have to discuss the affect of two things on every
relevant method, rather than just one).
[CK] If one is sufficient... of which I haven't been convinced :-)
<jra>
Your arguments aren't consistent. Here you imply workspaces aren't
sufficient while below you suggest they're too much.
</jra>


How is a checkout-token different from a workspace that has
the rule "checked-out to me; else the default revision"?
[CK] The difference, to me, is this.  A checkout-token represents
     a single thing.  It refers to a working copy of a specific
     revision of a specific resource along a specific line of descent.
     A workspace represents multiple resources and likely involves
     additional persisted state to represent the workspace.
     If I have a client that knows how to manage tokens, I don't
     want to have additional server state to track what I am
     already tracking.
<jra>
This is exactly the point. Distributed web application development isn't
about one specific revision of a specific resource along a specific line of
descent. Clients with checkout tokens just won't scale. Context needs to be
shared across many related resources, revisions, and logical changes. This
simplifies clients by having servers support richer versioning semantics.
Experience with WebDAV lock tokens also indicates this is a poor client
model, one I don't think we want to promote.
</jra>