Re: Version issues

Jim Whitehead (ejw@ics.uci.edu)
Thu, 1 Apr 1999 16:59:59 -0800 

From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 16:59:59 -0800
Message-ID: <003d01be7ca4$2203aea0$d115c380@ics.uci.edu>
Subject: Re: Version issues



-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] 
Sent: Thursday, February 25, 1999 10:39 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 02/25/99
12:30:21 PM

To:   Jim Amsden/Raleigh/IBM, 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
cc:
Subject:  RE: Version issues




<jra2>
Sure. But I'm still stuck on how a server will distinguish multiple working
resources checked out from the same revision.
</jra2>

[CK]One way is to have a checkout token which identifies each checkout.
    Then the server doesn't have to care -- it has a way to separate them.
    I don't know that the server wants to care about organizing checkouts
    as a general rule.  Workspaces, I think, are a mechanism that servers
    provide to help the client organize their work (views and checkouts).
    So what I'm saying is that workspaces provide a great abstraction on
    the store to help clients manage complexity.  However, clients may have
    their own way of managing complexity and fundamentally, the server is
    really just managing a set of revision graphs.
<jra3>
This sounds Ok except I don't think we want two mechanisms for identifying
working resources, checkout tokens and workspaces. Is there some way your
checkout token semantics could be described in terms of activities and
workspaces so we can have a consistent semantics? Then you client/server
could introduce whatever abstractions it wanted and we would be ensured of
interoperability because there is a common root semantic on which it is
based.
</jra3>