Next message: jamsden@us.ibm.com: "RE: Locking a workspace"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568F0.00085012.00@d54mta02.raleigh.ibm.com>
Date: Tue, 30 May 2000 21:30:42 -0400
Subject: RE: Why do we need working resource ids ?
Here's a couple of compelling use cases: the server generated URLs are not
likely to be in DAV namespaces. That is, collection semantics won't work.
They're only to access one specific resource. The collection semantics do
work with the versioned resource and Target-Selector. Second, we need
Target-Selector anyway for selecting revisions by label, workspace,
activity, perhaps baseline - all of which are logical target selectors that
have human meaningful names. We don't want clients to have to use server
generated URLs in some instances and versioned resource and
Target-Selectors in others in order to use the more meaningful names.
Personally, I think Target-Selector will be used 99% of the time with
either a label or workspace. The server generated URLs will probably be
rarely used.
Why do you discourage the use of the URL? I would think that
the use of a URL would be preferable to the use of a URL plus
a header. In particular, there are many places where the syntax
only allows a URL (such as an href element). For example,
we would no longer need a Destination-Target-Selector header
if we just used the URL, not to mention the xxx-Target-Selector
that we will have to introduce for every new xxx header that can
contain a URL.
Perhaps you or Jim could come up with some compelling use cases
that motivate having the working resource id in addition to the
working resource URL?
Cheers,
Geoff
-----Original Message-----
From: Henry Harbury [mailto:Henry.Harbury@merant.com]
Sent: Tuesday, May 30, 2000 4:22 PM
To: 'jamsden@us.ibm.com'; ietf-dav-versioning@w3.org
Subject: RE: Why do we need working resource ids ?
I agree with JimA. We generally discourage the use of the stable-url and
encourage the use of target selectors (where the id can be used) and
versioned resources. The stable-url is for down-level client support and
shouldn't be the cornerstone of the protocol.
-- Henry.
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Tuesday, May 30, 2000 6:45 AM
To: ietf-dav-versioning@w3.org
Subject: Re: Why do we need working resource ids ?
I think we need to keep uniformity between working resources and revisions.
When a working resource is checked out, the request-URL will be for the
versioned resource, and the Target-Selector will select the revision to
check out. (Note that I think Target-Selector should take a workspace,
label, revision id, etc.). The return value from checkout needs to be
something that can be applied in the Target-Selector along with the
versioned resource URL (the same one used on checkout) for subsequent
requests. This should be the working resource id. Alternatively, if the
client knows the working resource stable URL, that can be used as the
request-URL ignoring the Target-Selector header to access the same
resource. This is the same as for revision selection.
From: Edgar@EdgarSchwarz.de
a CHECKOUT returns a working resource id. Wouldn't it be possible
to drop that ? Normally a CHECKOUT works in the context of a
workspace (explicit or implicit). So I expect a server to give me
the working resource if I later GET and specify versioned resource
and workspace.
I believe Edgar makes an excellent point here. Until recently, our
answer would have been "because a server does not allocate a URL for
each working resource, and so a working resource id is required for
those working resources without their own URL's". But if we take the
design teams recommendation from last week and require that a server
provide a working resource URL for every working resource, then
working resource id's are no longer needed. I think this
significantly simplifies the protocol, so I vote to accept Edgar's
suggestion. We then just need an optional argument to the CHECKOUT
routine that tells the server to allocate a new URL for the working
resource (by default, the server would just use the request URL, just
as is done in a workspace context). In any case, the URL for the
working resource created by the CHECKOUT routine would be returned in
the Location response header.
BTW, the introduction to workspaces in 7.1 is too technical IMHO.
It should describe what we want to achieve with it. E.g. that it
is a filter or view which can help authors to coordinate their work.
Also I think a workspace server shouldn't define a 'request workspace',
but a 'user workspace' if no workspace header is given for a request.
I believe that this concern is addressed by the proposal to model a
workspace as just a special kind of collection. I'll try to get something
written up this week -- please let me know if the new description
provides a simpler model for workspaces (I believe it does).
Cheers,
Geoff