Next message: Tim Ellison OTT: "New version of scenarios document"
Message-ID: <B7DBED779F75CB47A4324902B6F54E13021E7230@RED-MSG-18>
From: Chris Kaler <ckaler@microsoft.com>
To: "'Bradley Sergeant'" <brads@responsys.com>, Neil Weber <Neil.Weber@merant.com>, ietf-dav-versioning@w3.org
Date: Mon, 14 Feb 2000 07:08:31 -0800
Subject: RE: Adding a DAV:default-revision property to versioned resources
I'm not opposed to have a "default revision" of a resource... in fact, I
proposed in in -00 :-).
However, we can't remove Workspaces from the Core functionality unless we
introduce some
notion of a "checkout token". We need a way for clients to manage their
checkouts.
Chris
-----Original Message-----
From: Bradley Sergeant [mailto:brads@responsys.com]
Sent: Friday, February 04, 2000 3:30 PM
To: Neil Weber; ietf-dav-versioning@w3.org
Subject: Re: Adding a DAV:default-revision property to versioned resources
Simple workspaces have been a required part of the spec for quite some time.
Sounds like Geoffrey's proposal is to remove Workspaces from the Core DeltaV
functionality.
As you point out Neil, for this to make sense you need to come up with a way
of dealing with working resources that does not require workspaces. This
could be done by forcing the client to reference the working resource via a
different URL. If you say that every client sees every other client's
working resource automatically when using the versioned resource URL then
you are really back to the default working resource functionality no matter
what you call it.
As I recall the reason we required a workspace in the core of DeltaV in the
first place was that it simplifies the overall protocol. You don't need two
different ways of dealing with working resources and revision selection. It
may be a conceptual leap, but simple workspaces do not appear to add
complexity to the client or the server. More justification would seem to be
needed to make such a change to the protocol.
--Sarge
----- Original Message -----
From: Neil <mailto:Neil.Weber@merant.com> Weber
To: ietf-dav-versioning@w3.org <mailto:ietf-dav-versioning@w3.org>
Sent: Friday, February 04, 2000 3:10 PM
Subject: RE: Adding a DAV:default-revision property to versioned resources
Geoff,
What about default workspaces do you feel is complex? I put together some
UML sequence diagrams and the handling of default workspaces fit in well.
Workspaces are not a required part of core versioning? From the extensive
discussion of workspaces in the spec I had the opposite impression. In
particular, the definition/specification of Target revolves around the
existance of a workspace. Suppose we have a versioned resource whose tip
revision is checked out. On a non-workspace server, is the target of a the
versioned resource the tip revision or the working resource?
Neil
-----Original Message-----
From: Geoffrey M. Clemm [ mailto:geoffrey.clemm@rational.com
<mailto:geoffrey.clemm@rational.com> ]
Sent: Friday, February 04, 2000 10:54 AM
To: ietf-dav-versioning@w3.org
Subject: Adding a DAV:default-revision property to versioned resources
In the spirit of minimizing the complexity of core versioning, I
propose we replace the "default workspace" core versioning concept
with a DAV:default-revision property for versioned resources. You
simply set this property (it is a live property, restricted to
revisions of the versioned resource) when you want to specify the
default revision.
An advanced versioning server will probably allocate some label
to represent the "default revision", but that's an implementation
decision that is left to the server implementor.
The DAV:workspace property of a working resource continues to be
the way to identify a working resource (e.g. in a Workspace header),
but in core versioning, the value of this property is an opaque
identifier. When a server supports workspaces, it would always
store an href as the value of the DAV:workspace property.
Comments?
Cheers,
Geoff