Next message: jamsden@us.ibm.com: "No DELTA-V Meeting at Adelaide"
Message-ID: <004401bf6f67$c7645820$8703a8c0@indius.com>
From: "Bradley Sergeant" <brads@responsys.com>
To: "Neil Weber" <Neil.Weber@merant.com>, <ietf-dav-versioning@w3.org>
Date: Fri, 4 Feb 2000 15:30:04 -0800
Subject: Re: Adding a DAV:default-revision property to versioned resources
RE: Adding a DAV:default-revision property to versioned resourcesSimple 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 Weber
To: 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]
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