RE: ... By the way ...

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

   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:

   CHECKOUT VCR
   => 409 Conflict
   <checkout-of-checked-out-version-is-forbidden>

   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"/>
 </D:property>
</D:expand-property>
  
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.

Cheers,
Geoff

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