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
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".

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
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.

Cheers,
Geoff
 

-----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:expected-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:expected-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:expected-ver
sion-URI>
  </D:error>

Received on Monday, 6 August 2001 20:46:44 UTC