Re: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

A couple of use cases that illustrate why you might want working
resources to only appear at the URL that was checked-out:

Shared-Workspace:

Two (or more) users are working on the same activity and want to see
each others checked-out work, so they are both working in the same
workspace.  If working resources are scattered about in server defined
locations, only the client that actually did the checkout would have
direct knowledge of where they are.  To share these resources, the
clients would have to implement some mechanism for tracking down these
working resources.  Rather than have clients try to do this (in
various non-interoperable ways), the server could be required to 
make the working-resource visible at the checked-out URL.

Testing-Before-Checkin

A developer would like to test the contents of working resources before
checking them in.  This involves link-validity checking, and in case
the working resources contain code, running some builds and testing
the results.  If working-resources are scattered about in temporary
locations, the link-validity check will fail to find the changes, as
will the code builds.  As with the previous use case, this problem is
solved by requiring the server to make the working resource visible
at the checked-out URL.

Cheers,
Geoff

Received on Monday, 8 February 1999 09:27:52 UTC