Next message: Clemm, Geoff: "DAV:revisions property for a workspace resource"
Date: Wed, 12 Apr 2000 09:09:07 -0400 (EDT)
Message-Id: <200004121309.JAA12354@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Unversioned members of versioned collections
From: jamsden@us.ibm.com
<geoff> The semantics of an unversioned resource is that a PUT to
that resource is seen by the next GET to that resource. =A0This
means that two workspaces cannot have their own copies of that
resource, but must share a common resource. 0In contrast, each
workspace can have its own copy of a revision, since it is
immutable. </geoff>
<jra> OK, I think I'm getting there. Say you have a versioned
collection http://domaing/401k/images. Now say that versioned
collection has a member arrow.ico. The collection has a member
arrow.ico which is a binding to something somewhere. Workspaces
that select collection 401k have a "copy" of that collection with a
member that contains the binding. Not say arrow.ico is an
unversioned resource. Workspace selection is involved in selecting
a revision of collection 401k containing member arrow.ico which is
a binding to an unversioned resource. It doesn't do anything to
select a revision of the bound to resource as it is not
versioned. This would be true of all workspaces that select any
revision of 401k that contained a member referencing the same
unversioned resource. So I don't see the problem. The two
workspaces don't contain copies of arrow.ico, but rather 401k which
contains bindings to arrow.ico. </jra>
The problem is that every collection revision in every workspace
everywhere on the net would have to somehow keep a reliable reference
to this shared unversioned resource, and would have to forward
all requests to that shared unversioned resource whenever any method
was invoked on that member of the collection.
This effectively limits all workspaces to be on a single server, since
cross-server bindings are unlikely to implemented frequently, if at
all. This effectively eliminates any ability to have a versioning
implementatin that scales, since you will not be able to assign
different workspaces that share underlying versioned resources to
different servers.
In contrast, what is the central use case being addressed by making
unversioned resources members of versioned collections? I haven't
heard any motivations beyond "clean design" and "generality", which
I find less than compelling.
Cheers,
Geoff