Next message: Clemm, Geoff: "RE: Revision of a stable-URL versioned resource"
Message-ID: <65B141FB11CCD211825700A0C9D609BC025FA320@chef.lex.rational.com>
From: "Clemm, Geoff" <gclemm@Rational.Com>
To: ietf-dav-versioning@w3.org
Date: Thu, 6 Apr 2000 00:33:41 -0400
Subject: RE: Stable URLs
From: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com]
(4) There is no visible 'meta' area of a server URL
namespace. The
stable URL space is the exclusive domain of the server.
Adding a header that says "switch to a completely different
namespace"
is pretty drastic. In particular, why not just use existing
namespace
functionality, namely, let the server allocate a meta area of the
server URL namespace, or let the server introduce a "metadata
virtual
host"? What does the separate namespace buy you that makes up for
the
cost of needing these "stable" flags in the Workspace and
Revision-Selector headers.
<tim/> This came from the requirement to not have any part of the
user's
URL space hijacked by the server for storing metadata. I remember
previous
long discussions about this.
It buys you the ability to say to clients 'no part of the namespace
is out
of bounds to you'.
A problem with saying that the stable URL is only usable with a special
header is that it makes it unusable by a versioning unaware clients.
Since this was the use case that most concerned JimW, I doubt he would
find this approach satisfactory.
Wouldn't the use of "virtual hosts" suffice for those servers
that wish to give a client complete control of the namespace at a
particular host?
For example, a server could store the stable URL's for a host named
"my.foo.com" at a virtual host named "metadata.my.foo.com".
- Methods have the same effect if applied to a resource via its
dynamic
or
stable URL.
I don't agree with the last axiom. There will be some methods (such
as
MOVE) which will fail for a stable URL but succeed for a dynamic
URL.
There are other methods (such as depth:infinity PROPFIND) that will
have
a different effect in stable and dynamic URL space.
<tim/>Methods such as MOVE would allow the source to be given as a
stable
URL, I agree that the destination may not be stable.
I don't see why depth:infinity would have a different effect, since
it
means go to the (collection) resource with the given stable URL,
then
follow its members deep. How you got to the resource is immaterial.
A MOVE has to take the resource out of the current collection and add it to
the Destination collection. The key semantic of a stable URL is that any
MOVE on that URL will fail. Whether or not the Destination is stable is not
the issue.
As for depth:infinity, suppose you applied the PROPFIND to a revision of
a versioned collection. In dynamic space, it will return you whatever
resources are currently selected by the workspace as members of that
revision.
In stable space, it returns the set of versioned resources bound into that
collection revision. My point is just that the effect of a method on a
stable URL to a resource can be different from the effect of a method on a
dynamic URL to that same resource.
If you make the stable namespace a consistent WebDAV namespace, then
PROPFIND will return reasonable member names which will give you the
information you want ... why didn't you want the stable namespace to
be a consistent WebDAV namespace?
<tim/>How will the client/server know which parts of the URL are
stable,
and which are not?
The server certainly knows what parts of the namespace are stable ... it
just
picks certain URL's and says "everything under this URL is stable". I'm not
sure what scenarios require a client to know what parts of the namespace are
stable, but there probably are some. Probably the most natural thing to do
is
to have the DAV:default-workspace report return a special value when applied
to stable namespace.
<tim/> http://foo.com/RID:9/REV:12/bar
is this a RID:9 member in collection '/' or the start of a stable
URL?
is REV:12 a member of the revision selected for the (collection)
resource
'/RID:9/' or a continuation of the stable URL?
Making the name a consistent namespace means that the client can
'interpret' or 'decode' the resource URN -- I don't think this makes
sense.
I maintain that there should be collections in the stable namespace. In
particular,
the spec currently states that there can be specific collections in the
stable namespace
in which servers may require that all versioning metadata (such as
activities and
baselines) be placed. So in your example, suppose /RID:9 is a stable URL.
For there
to be a resource /RID:9/REV:12, /RID:9 MUST identify a collection.
Similarly, for
/RID:9/REV:12/bar to identify a resource, /RID:9/REV:12 MUST identify a
collection.
Now if you want the binding name to contain a "/", you just encode it with
standard
URL escaping mechanisms.
So the bottom line is that I agree with most of your description, except for
requiring
a special header be used to access stable URL's, and that the effect of a
method on
a stable URL to a resource will always be the same as the operation on a
dynamic URL
to a resource.
Cheers,
Geoff