Re: Version issues

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

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



-----Original Message-----
From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent: Sunday, February 28, 1999 9:36 PM
To: ckaler@exchange.microsoft.com
Cc: jamsden@us.ibm.com; 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).

How is a checkout-token different from a workspace that has
the rule "checked-out to me; else the default revision"?

Note: we're not talking implementation here, just protocol semantics.

Cheers,
Geoff


   From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>

   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>