Re: Version issues

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

From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 17:00:00 -0800
Message-ID: <003e01be7ca4$22792cc0$d115c380@ics.uci.edu>
Subject: Re: Version issues



-----Original Message-----
From: Chris Kaler (Exchange) [mailto:ckaler@exchange.microsoft.com]
Sent: Thursday, February 25, 1999 11:34 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



I guess I don't see why two is bad -- I think they compliment each other,
not conflict.

There is a thing which identifies a checkout.  Clients can choose to manage
this information themselves, or they can make use of a workspace to manage
it for them.  Workspaces provide the following advantages:
- they manage the checkout thingies
- they provide a consistent view on the store
- they organize work into non-overlapping units
- they track, via activities, changes

I like the differentiation because clients can do more work or less work and
they get to choose.  As well, we have an interoperable solution.

Just my two cents...

Chris

-----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; Chris Kaler (Exchange);
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>