Next message: Geoffrey M. Clemm: "Re: Target-Selector"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256854.0072080B.00@d54mta03.raleigh.ibm.com>
Date: Mon, 27 Dec 1999 15:45:47 -0500
Subject: Re: Target-Selector
I agree with Geoff. I had proposed a revision-selector, override-selector
pair making them generic and able to take any WebDAV revision selector
(label id, label, activity, configuration, baseline, or workspace).
However, I agree that efficient data access will demand that the one
playing the revision-selector role can only practically be a workspace, so
why not call it that? For the override-selector, I might still stick with
this name as it more clearly indicates the role the header is playing.
Using Workspace and Revision-Selector makes it less clear that the
Revision-Selector is never used by itself. If the Workspace header is not
specified, the default workspace is used, so the Revision-Selector is
always used to override a workspace.
Now we need another pair for those methods that specify a destination. I
suggest Dest-Workspace, Dest-Override-Selector or some such names.
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 12/27/99
03:26:45 PM
Sent by: ietf-dav-versioning-request@w3.org
To: ietf-dav-versioning@w3.org
cc:
Subject: Re: Target-Selector
Efficient data access in the presence of versioning will be all about
caching (just as is the case for efficient access in the non-versioned
case). It is important for the headers to be significant to the
behavior of proxies and other caching mechanism (otherwise you should
just place this information in the request body).
Semantically, the versioning "workspace" concept is all about producing
a "private" or "separate" place to do your work, and is the natural
object for caching (and scaling ... you scale by locating different
workspaces on different servers).
Thus the Workspace is a key piece of information to make visible to
the proxies in the form of a header. An additional piece of key
information is whether you are going to "override" the behavior of the
Workspace with a Revision-Selector. This forces the request to be
dispatched back to the server holding the versioned resource, since
the Revision-Selector overrides the contents selected by the
workspace. Having the Revision-Selector override only apply to the
last segment of the URL is important, since having it apply to
anything else would involve a complicated dialog between the server
holding the workspace and the server holding the versioned resources.
So I will continue to vote heavily in favor of two headers:
a Workspace header and a Alternative-Revision (aka "Revision-Selector")
header (I'd be happy to rename the second header, but not change its
semantics :-).
Cheers,
Geoff
From: Tim_Ellison@oti.com (Tim Ellison OTT)
I'd really like to have both a Workspace: header and a
Revision-Selector:
since it seems that a common operation, when dealing with history, is to
check-out a particular revision into a given workspace.
Presently, we only have a single selector that specifies the workspace
to
both select the revision and contain the working resource. There is,
for
example, no means of requesting a check-out of a labeled revision into a
named workspace -- and I think that will be a common requirement. The
solution at the moment is to PROPFIND the stable revision URL using the
label selector, then checkout with the workspace selector.
I think 'workspace' would be a good candidate for addition to the
headers.
Here's my renditioning of a full-on selection:
CHECKOUT /colln1/colln2/foo,html HTTP/1.1
Target-Selector: label:Release1.0; finally label:bugfix
Workspace: http://www.wedav.org/myworkspace
which reads: checkout /colln1/colln2/foo.html by selecting the revision
of
colln1 and colln2 labeled Release1.0 and the revision of bugfix labeled
foo.html into the workspace 'myworkspace'.
Tim
----------
>From: jamsden
>To: ietf-dav-versioning
>Subject: RE: Target-Selector
>Date: Wednesday, December 22, 1999 4:10PM
>
>How about sticking with separate headers as they are simpler and easier
to
>parse than one. I suggest headers that reflect the roles the values are
>playing rather than their types. For example, Revision-Selector for
the,
>well, revision selector, and Override-Selector for the leaf if the
revision
>selector is being overridden. This is the same as Geoff's proposal, but
it
>keeps the notion of Workspace out of the Revision-Selector so we could
>potentially use other things there like a label, configuration,
revision
>id, activity, etc.
>
>
>
>
>
>Tim_Ellison@oti.com (Tim Ellison OTT)@w3.org on 12/22/99 02:06:36 PM
>
>Sent by: ietf-dav-versioning-request@w3.org
>
>
>To: ietf-dav-versioning@w3.org ('Delta V')
>cc:
>
>Subject: RE: Target-Selector
>
>
>
>I stand by my original proposal, although I agree we are only differing
by
>syntax.
>
>Firstly, I would prefer not to have two headers simply because it
promotes
>header bloat (would that be Workspace:, Revision-Selector:,
>Desination-Workspace: and Destination-Revision-Selector:?).
>
>I find the name Target-Selector quite meaningful (as these things go
:-)
>and
>a finally clause more intuative than recognising the overriding nature
of
>Revision-Selector/Workspace headers.
>
>Secondly, using 'keyword-space-value' is, as you would say, morally
>equivalent to a URI. By specifying as URIs you have a natural forward
>compatibility solution that you cannot otherwise guarantee.
>
>... and finally, having to specify "configuration" is redundant since
the
>server will have to ensure the following URL really is a configuration
and
>not another type.
>
>So my objections are more on (relatively trivial) implementation
grounds
>than the semantics of our solution.
>
>Tim
> ----------
>From: Geoffrey M. Clemm
>To: ietf-dav-versioning
>Subject: Re: Target-Selector
>Date: Wednesday, December 22, 1999 1:28PM
>
>I'd like to propose a syntactic variant on Tim's proposal:
>
>Instead of adding a "finally" clause to the Target-Selector header,
>let's replace the "Target-Selector" header with a "Workspace" and a
>"Revision-Selector" selector header. One advantage is that
>Workspace and Revision-Selector are more self-explanatory than
>Target-Selector.
>
>A Workspace header specifies either a Workspace URL or nothing,
>where nothing corresponds to the old "metadata" Target-Selector.
>A Revision-Selector specifies a label, an id, or a configuration.
>A Workspace header specifies target selection for the entire request.
>A Revision-Selector header overrides the Workspace header for the
>versioned resource identified by the Request-URL.
>
>
>workspace-hdr = "Workspace" ":" [ URL ]
>revision-selector-hdr = "Revision-Selector" ":" revision-selector
>revision-selector = "id" segment
> | "label" segment
> | "configuration" URL
>
>I'd like to keep the "id", "label" and "configuration" keywords
>to avoid ambiguity in case we decide to extend those namespaces.
>
>Cheers,
>Geoff
>
> From: Tim_Ellison@oti.com (Tim Ellison OTT)
>
> I'd like to propose a change to the Target-Selector as described in
the
> protocol spec.
>
> Presently, the valid values are:
> workspace "<URI>"
> id "<revision id>"
> label "<label>"
> metadata
>
> The change would accomodate the situation where the client wants to
>select
> collection revisions using a workspace, and the final resource using
a
>label
>
> or id. Without such a change the "id" target selector is of
little/no
>use
> for selecting resources in collections (the collection will not have
the
> same id as the "leaf" resource).
>
> The change would also allow the client to select a revision based
>directly
> upon an activity and provides extensibility for other selection
schemes.
>
> target selector = Target-Selector ":" URI [ LWS "; finally" URI ]
>
> The use of URIs gives us extensibility for defining new selection
> mechanisms, and the optional "finally" clause allows clients to
specify
>a
>
> different selector for the leaf. (I don't see any benefit for N
>selection
> methods.)
>
> Example URIs would be id:some_id, label:some_label, metadata:, and
> http://machine/resource where 'resource' is a workspace or activity
or
> something else (the server gets to figure out which by looking at
the
> resource type). Specifying a resource that cannot be used for
selection
> results in a bad request.
>
> Example target selectors would be:
> Target-Selector: http://foo.com/mywork
> Target-Selector: http://foo.com/mywork ; finally id:Rev12FP
> Target-Selector: label:bar ; finally http://foo.com/actif1
>
> Comments?
> Tim
>
>
>
>
>
>
>