RE: Feature request for CHECKIN/OUT extension

It seems he wants CHECKOUT to return a location header for
checkout-in-place.

Since I just changed my code when I noticed that CHECKIN in
checkin-in-place generated a location header, this wouldn't be hard for
me to do.

But the problem remains for all those servers that *don't* know what the
value is permanently.  I guess you could always give them the temporary
one -- like you generate a temporary one for working resources.

Note: I don't care if this is there are not.

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of 
> Julian F. Reschke
> Sent: Tuesday, August 07, 2001 12:04 AM
> To: Clemm, Geoff; ietf-dav-versioning@w3.org
> Subject: RE: Feature request for CHECKIN/OUT extension
> 
> 
> Geoff,
> 
> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> > Sent: Monday, August 06, 2001 8:07 PM
> > To: ietf-dav-versioning@w3.org
> > Subject: RE: Feature request for CHECKIN/OUT extension
> >
> >
> > Perhaps you could explain what benefit this "expected version URL" 
> > would provide.  In the W3C, you have a human meaningful URL, which 
> > DeltaV would call the version-controlled resource.  The resource
> 
> In W3C we have both:
> 
> 1) the URI of the version controlled resource, for instance 
> <http://www.w3.org/TR/xslt> points to the "latest" version of 
> the XSLT recommendation.
> 
> 2) we also have URIs for the equivalents of the checked-in 
> versions, for instance 
> <http://www.w3.org/TR/1999/REC-xslt-19991116> will always 
> refer to the XSLT recommendation published on Nov 16, 1999. 
> *Right now*, it refers to the same document.
> 
> Note that the document referred by 
> <http://www.w3.org/TR/1999/REC-xslt-19991116> *contains* this 
> URI as part of it's content. Under deltaV this means that a 
> client must be able to know the URI of the version (when 
> checked-in) before actually doing the CHECKIN to accomplish the same.
> 
> > at this URL has a property that points at the latest immutable 
> > version, which DeltaV calls the DAV:checked-in version.  I am not 
> > aware of the W3C having a URL for "the next version that will be 
> > created".
> 
> I didn't say that (hopefully :-).
> 
> > Many versioning repositories do not allocate the version 
> URL until the 
> > version is actually created, and therefore would not support the 
> > "expected version" feature.  In particular, for a repository
> 
> Sure. So does ours. But it generally will use an (internally) 
> well-defined mechanism to allocate the next URI, so a server 
> possibly could pass the information about the *expected* next 
> checkin URI to the client unpon checkout. If it can't provide 
> it, it doesn't need to (and a client will have to live with 
> this). If it does provide it, but upon CHECKIN the server 
> decides it can't use that URI after all, the client will get 
> an error message (allowing him to recover).
> 
> > that supports branching and unreserved checkouts, the 
> client that gets 
> > a particular version URL depends on which client checks in 
> first.  I 
> > would be reluctant to add a feature like this which will cause 
> > interoperability problems, unless there is a compelling use 
> case that 
> > requires it.
> 
> 1) If the feature is implemented as outlined below, it 
> shouldn't cause interoperability problems. Servers can signal 
> that they can't determine the "expected checkin URI". If they 
> do, they are also free not to accept this URI upon CHECKIN 
> (and to produce a new one). This would happen in the case you 
> mentioned.
> 
> 2) I think I have given the use case. It basically requires 
> that a checked-in version can carry it's own URI (of the 
> checked in version) in it's content. This is a mandatory 
> requirement for the versioning system we have to expose 
> through WebDAV, so we have to either define a proprietary way 
> to achieve this, or the protocol needs an extension. We think 
> this use case may apply to many others, and this is why we 
> are trying to get a discussion and possibly a consensus here...
> 
> Regards, Julian
> 
> > -----Original Message-----
> > From: Julian F. Reschke [mailto:julian.reschke@greenbytes.de]
> > Sent: Monday, August 06, 2001 10:50 AM
> > To: ietf-dav-versioning@w3.org
> > Subject: Feature request for CHECKIN/OUT extension
> >
> >
> > Feature request for CHECKIN/OUT extension
> >
> > In many cases, a versioning-aware client might want to 
> display/include 
> > the URI of the version it's editing *while* it's edited. 
> For instance, 
> > a versioning aware editor might include this as 
> meta-information, or 
> > the author of a document might want to know the URI of the version 
> > *before* it's checked in.
> > A well-known example is the W3C way of referring to 
> document versions in
> > recommendations: it contains HREFs to "the current 
> version", to "this
> > version"
> > and to the "previous version". Something like this is 
> currently impossible
> > with deltaV, as the version URI is determined at the time 
> of CHECKIN.
> >
> > Proposal:
> >
> > 1) Extend CHECKOUT to optionally return an "expected CHECKIN URI".
> > 2) Extend CHECKIN to optionally use the "expected CHECKIN URI", 
> > failing the request if it's not possible to checkin the 
> resource with 
> > the desired version URI (in which case a new "expected 
> CHECKIN URI" is 
> > returned).
> >
> > Some possible strategies:
> >
> > 1) Pass the information as proprietary live properties.
> > 2) Pass the information as properties in the DAV: namespace, and 
> > define the behaviour in the deltaV spec.
> > 3) (preferred) Pass the information in the request/response 
> bodies of
> > CHECKIN / CHECKOUT, such as:
> >
> > CHECKOUT method:
> >
> > >>REQUEST
> >
> >   CHECKOUT /foo.html HTTP/1.1
> >   Host: www.webdav.org
> >   Content-Type: text/xml; charset="utf-8"
> >   Content-Length: xxxx
> >
> >   <D:checkout xmlns:D="DAV:">
> >     <D:compute-expected-version-URI />
> >   </D:checkout>
> >
> >
> > >>RESPONSE
> >
> >   HTTP/1.1 200 OK
> >   Cache-Control: no-cache
> >   Content-Type: text/xml; charset="utf-8"
> >   Content-Length: xxxx
> >
> >   <D:checkout xmlns:D="DAV:">
> >
> > <D:expected-version-URI>http://repo.webdav.org/his/23/ver/32</D:ex
> > pected-ver
> > sion-URI>
> >   </D:checkout>
> >
> >   (Note that we would need to define an (optional) response 
> body for 
> > CHECKOUT).
> >
> >
> > CHECKIN method:
> >
> >
> > >>REQUEST
> >
> >   CHECKIN /foo.html HTTP/1.1
> >   Host: www.webdav.org
> >   Content-Type: text/xml; charset="utf-8"
> >   Content-Length: xxxx
> >
> >   <D:checkin xmlns:D="DAV:">
> >
> > <D:expected-version-URI>http://repo.webdav.org/his/23/ver/32</D:ex
> > pected-ver
> > sion-URI>
> >   </D:checkin>
> >
> > >>RESPONSE
> >
> >   HTTP/1.1 201 Created
> >   Location: http://repo.webdav.org/his/23/ver/32
> >   Cache-Control: no-cache
> >
> >   or
> >
> > >>RESPONSE
> >
> >   HTTP/1.1 409 Forbidden
> >   Cache-Control: no-cache
> >   Content-Type: text/xml; charset="utf-8"
> >   Content-Length: xxxx
> >
> >   <D:error xmlns:D="DAV:">
> >     <D:cannot-assign-expected-version-URI />
> >
> > <D:expected-version-URI>http://repo.webdav.org/his/23/ver/33</D:ex
> > pected-ver
> > sion-URI>
> >   </D:error>
> >
> >
> >
> >
> >
> 
>

Received on Thursday, 9 August 2001 12:31:43 UTC