Re: Version issues

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

From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 17:04:40 -0800
Message-ID: <004c01be7ca4$c94e8680$d115c380@ics.uci.edu>
Subject: Re: Version issues



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



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>
[CK2] Two points - and they represent different customer segments.
      (1) This isn't my model.  I have lots of unrelated documents
          and, as a level 1 client app, this complicates everything.
      (2) There are cases, NT for example, where workspaces will have
          real scalability problems.  I may want/need to manage the
          state on the client not the server.

      I think our protocol must allow for state to be managed on the
      client or the server.  We can dictate one over the other.