W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

RE: Feature request for CHECKIN/OUT extension

From: Julian F. Reschke <julian.reschke@greenbytes.de>
Date: Thu, 9 Aug 2001 22:29:52 +0200
To: "John Hall" <johnhall@evergo.net>, "'Clemm, Geoff'" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCMEINCNAA.julian.reschke@greenbytes.de>
Hi John,

as I said earlier -- if a server can't compute that URI -- no problem, a
portable client will have to live with this.

The point being: *if* a server is able to supply this information, I'd
prefer this information to be available in a portable way.

> -----Original Message-----
> From: John Hall [mailto:johnhall@evergo.net]
> Sent: Thursday, August 09, 2001 6:32 PM
> To: 'Julian F. Reschke'; 'Clemm, Geoff'; ietf-dav-versioning@w3.org
> Subject: 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 16:30:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:42 GMT