Next message: Geoffrey M. Clemm: "Re: Simplifying client access to advanced versioning"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568C8.0057ED22.00@d54mta03.raleigh.ibm.com>
Date: Fri, 21 Apr 2000 12:00:18 -0400
Subject: Re: Simplifying client access to advanced versioning
Geoff,
I like most of your proposals below, but the SET-TARGET method seemed a bit
hard to understand. Too many combindations of the method and its headers
doing too many different things. I think we should keep the LABEL method as
simply a way of adding and removing labels on a revision. These don't have
to have anything to do with target selection at the moment.
|------------------------+------------------------>
| | "Clemm, Geoff" |
| | <gclemm@rational.com>|
| | Sent by: |
| | ietf-dav-versioning-r|
| | equest@w3.org |
| | |
| | 04/15/2000 10:59 AM |
| | |
|------------------------+------------------------>
>------------------------|
| |
| To: |
| "DeltaV (E-mail)" |
| <ietf-dav-versioning@|
| w3.org> |
| cc: |
| Subject: |
| Simplifying client |
| access to advanced |
| versioning |
>------------------------|
One of the current aspects of the protocol that is designed
to provide consistent client access to core and advanced
versioning functionality, is that the same methods and headers
are used when a working resource is identified by a working-resource-id
and when it is identified by a workspace.
I believe that we can achieve an analogous increase in consistency
if we modify the marshalling so that the same methods and headers
are used when a set of revisions are identified by a label,
and when they are identified by a workspace. Note that this is
very similar to the working-resource-id/workspace relationship,
in that core versioning uses a string (a label), while advanced
versioning uses a resource (a workspace).
One way to make this change is to rename our two headers (once again :-)
to be "Request-Target-Selector" (that applies only to the request URL)
and "Target-Selector" (that applies to all the other resources encountered
during a request). Note that this is the same semantics as we have at
the moment, so it is just a rename of the headers, not a semantic change.
But then let's allow a Target-Selector (aka Workspace) header to specify
either a label or a workspace. Now we can use a label for the things
we used to only be able to do with workspaces (e.g. specify that this
label should be used for every resource in a Depth:infinity PROPFIND
request).
Then we can replace the LABEL and SET-DEFAULT-REVISION methods with a
single SET-TARGET method. The SET-TARGET method makes the specified
Target-Selector (i.e. workspace or label) select the revision identified
by the Request-Target-Selector header. If no Target-Selector header is
specified, a core client thinks of this as "setting the default target"
while an advanced client thinks of this as "specifying the target in the
default workspace". In either case, it has the desired effect, i.e. that
is the revision you get if you specify no target selection headers in your
request.
So to set the default revision to be rev-3, you'd say:
SET-TARGET /foo
Request-Target-Selector: rev-3
Then the next time you said:
GET /foo
you'd get rev-3.
Then to make the label "tested" select rev-8, you'd say:
SET-TARGET /foo
Target-Selector: tested
Request-Target-Selector: rev-8
Then the next time you said:
GET /foo
Target-Selector: tested
you'd get rev-8.
Then to make the workspace named http://www.webdav.org/ws/my-ws select
rev-12, you'd say
SET-TARGET /foo
Target-Selector: http://www.webdav.org/ws/my-ws
Request-Target-Selector: rev-12
Then the next time you said:
GET /foo
Target-Selector: /http://www.webdav.org/ws/my-ws
you'd get rev-12.
I think this then not only simplifies the client model, but provides a more
uniform set of concepts grouped around the notion of a "target".
Comments?
Cheers,
Geoff