Next message: Tim Ellison OTT: "RE: Adding a DAV:default-revision prope"
Message-Id: <3.0.5.32.20000216162153.02be19c0@127.0.0.1>
Date: Wed, 16 Feb 2000 16:21:53 -0500
To: ietf-dav-versioning@w3.org
From: "Clemm, Geoff" <gclemm@Rational.Com> (by way of "Ralph R. Swick" <swick@w3.org>)
Subject: RE: Adding a DAV:default-revision property to versioned resources
[ caught in spam filter -ralph
Message-ID: <65B141FB11CCD211825700A0C9D609BC01F094D2@chef.lex.rational.com>
]
> From: Chris Kaler
>
> I'm not opposed to have a "default revision" of a resource...
> in fact, I proposed in in -00 :-).
Yes, that's where I took it from.
> 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.
The proposal is not to remove workspaces from the Core,
but to restrict their use in the Core to just being
a "checkout token". (See the original posting, quoted
below).
> From: Bradley Sergeant [mailto:brads@responsys.com]
>
> 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.
The proposal is only to move "extended workspaces" (i.e.
a workspace that does revision selection in addition to
working resource selection) into Advanced Versioning.
> 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.
There are already two ways of performing revision selection:
either by explicit label/revision-id, or by the revision
selection rule of a workspace. The proposal is to just provide
the first way (explicit label/revision-id) in Core versioning,
and introduce the concept of a revision selection rule in
Advanced Versioning.
A working resource is always selected by a workspace.
> 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.
When we introduced the notion of a "default workspace", there were
objections from folks (e.g. Chris and Bruce) that represented
"core versioning" clients and servers. Recently, Chris raised
the issue that core versioning is still too complicated. I'd like
to address his concern, and this seemed like one way to do so.
> From: Neil Weber
> 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.
The main overhead is introducing a new resource type (i.e.
a workspace) whose semantics the server and client must understand.
If a workspace only provides working resource
identification, it can just be a string.
> Workspaces are not a required part of core versioning? From
> the extensive discussion of workspaces in the spec I had the
> opposite impression.
In the proposal, a workspace is still used in Core versioning
to identify working resources ... it just is not a resource
and therefore has no properties.
> 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?
If a Revision-Selector header is specified, the specified
revision is the target. If a Workspace header is specified,
the specified working resource is the target. If neither
header is specified, the DAV:default-revision of the versioned
resource is the target.
Cheers,
Geoff
> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
>
> 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?