Re: Version issues
Jim Whitehead (ejw@ics.uci.edu)
Thu, 1 Apr 1999 17:03:54 -0800
From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 17:03:54 -0800
Message-ID: <004801be7ca4$ae09a120$d115c380@ics.uci.edu>
Subject: Re: Version issues
-----Original Message-----
From: Chris Kaler (Exchange) [mailto:ckaler@exchange.microsoft.com]
Sent: Thursday, March 11, 1999 6:02 PM
To: 'Geoffrey M. Clemm'
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).
[CK] If one is sufficient... of which I haven't been convinced :-)
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.
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>