Next message: Edgar@EdgarSchwarz.de: "A Plea for the workspace header (Was: Why do we need working resource ids ?)"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568F0.006F7991.00@d54mta02.raleigh.ibm.com>
Date: Wed, 31 May 2000 16:17:34 -0400
Subject: Re: workspaces as collections
I (still) agree -- this is a useful simplification.
Given that we are allowed to define the (opaque) working resource id to
look like a URL, there is nothing to stop the server using the working
resource URL as its id, so let's drop the working resource id and simplify
the description.
<jra>
I think this is what I was missing, using the working resource or revision
URL in the Target-Selector. If that is the plan, then I'm all for it.
</jra>
Tim
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
Sent by: ietf-dav-versioning-request@w3.org
30-05-00 10:17 PM
To: ietf-dav-versioning@w3.org
cc:
Subject: Re: workspaces as collections
From: jamsden@us.ibm.com
We don't want users to have to use server generated URLs.
I'd expand that to say "We don't want users to have to use
server generated URL's or server generated id's".
A user never wants to use/remember server generated strings,
whether we call them URL's or id's.
We want them to use versioned resource URLs and the
Target-Selector header.
Users won't be using Target-Selector headers in any case,
client programs will. (I suppose a few users might explicitly type
in HTTP requests, but I predict not many :-).
A client program on the other hand will be responsible for
generating the HTTP requests, and I don't see how a client
program would find it preferable to pass a server-defined
id in a Target-Selector header rather than a server-defined
URL as a request-URL. To the contrary, I believe a client
program will find it much easier to pass the URL through its
marshalling logic, rather than passing both a URL and some
id, and remembering to marshal the id in the appropriate header.
This is even more true when it has to deal with several URL's
(such as the Destination for a COPY or MOVE request). Here it
would have to pass around two URL's and two id's, and remember
to assign one id to the Target-Selector header and the other id
to the Destination-Target-Selector header. And it also has
to remember whether it is a revision id or a working resource id,
because that has to be specified in the Target-Selector header
as well. The URL's are starting to look pretty good to me by now (:-).
So I think the versioned-resource and working-resource-id
case are still needed. Simpliciy comes from uniformity.
Actually, I think simplicity comes even more from simplicity (:-).
To me, having:
- a versioned resource URL
- a revision URL
- a versioned resource URL with a label in a Target-Selector header
- a working resource URL
- a history URL
is simpler than having:
- a versioned resource URL
- a revision URL
- a versioned resource URL with a version id in a "version-id" variant
of a Target-Selector header
- a versioned resource URL with a label in a "label" variant of a
Target-Selector header
- a working resource URL
- a versioned resource URL with a working resource id in a
"working-resource-id" variant of a Target-Selector or
Destination-Target-Selector header
- a history URL
- a versioned resource URL with the "versioned-resource" variant of the
Target-Selector header
Also notice the nice interaction with Depth requests ... a depth
request with a Target-Selector containing a label makes perfect sense,
while a depth request with a Target-Selector containing a server
defined revision id or server defined working resource id will
virtually never be useful.
It looks like we can throw out all the bathwater while maintaining
a firm grip on the baby (:-).
Cheers,
Geoff