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

RE: ... By the way ...

From: Clemm, Geoff <gclemm@rational.com>
Date: Sun, 15 Jul 2001 22:34:38 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103A3864B@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org

   From: John Hall [mailto:johnhall@evergo.net]

   As I understand it, there is no way for a client to tell that a
   working resource has been created.

   VCR checked in, no working resources have been created.  Server
   doesn't allow forking.  Server supports WORKING-RESOURCE and

   ClientA: CHECKOUT <apply-to-version> VCR.
   => creates working resource and leaves VCR untouched.

   ClientB: Since VCR is untouched, it is impossible to detect that
   CLientA has performed their operation.  Therefore:

   => 409 Conflict

   Is there some way I'm missing that Client B could have seen this
   one coming?

Use the DAV:expand-property report to ask for the checkout-set and
checkout-fork properties of the checked-in version, i.e.:

<D:expand-property xmlns:D="DAV:">
 <D:property name="checked-in">
   <D:property name="checkout-set"/>
   <D:property name="checkout-fork"/>
If the checkout-set is non-empty and checkout-fork is forbidden,
you know the checkout will fail.

   Currently, I don't support forking so only 1 checkout (INPLACE or
   WORKING) is allowed.  But if I did support multiple checkouts, I'd
   still keep a count so I could tell Client B, that forking was
   'discouraged', for example.

Yes, if the checkout-fork is discouraged, that would be something
you'd want to warn them about (and if they said "do it anyway", you
would know to include the DAV:fork-ok flag with the CHECKOUT).

   Are people implementing this without tracking the count of working
   resources created off the versions of a VCR?

The list of checkouts is important, which is why the server is
required to maintain DAV:checkout-set.

Received on Sunday, 15 July 2001 22:35:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC