Version History Resource (was: PROPFIND instead of REPORT)

   From: "Lisa Dusseault" <lisa@xythos.com>

   Now it seems you're saying the resource URL and the
   version-history-resource URL are two different things, so the
   entire count is n+2.

Note that I take the current consensus to be to make version history
resources an option, so my follow-up is to make sure there is no
confusion about the difference between a version-controlled resource
and a version history.

First, I'll point out I'm a bit unimpressed by the jump from
"n+1" to "n+2".  Whatever technique you are using to allow you
to have "n" additional URL's for the resource, it is hard to imagine
it being other than trivial to support one more (computers are
really good at doing N+1 things once you've programmed them to do
N things :-).

But back to the more substantive question why a version history
resource.

There are a variety of benefits to distinguishing a version-controlled
resource from a version history.  For example, if you lock the version
history, no new versions can be added to the history (you've locked
the DAV:version-set).  If you lock the version-controlled resource
(the more normal thing to do), you just lock that resource and
parallel development can continue to add new versions to the history
resource.

   If that's the case, then I'm dead against requiring a version-history
   resource for servers implementing CORE.  Make the list of versions be a
   property on the version-controlled resource,

If you did that, you'd lose the ability to decide whether to
lock the version history, or just the version controlled resource.
Similarly, you'd lose the ability to differentiate between
"when was the history last modified (i.e. a new version added)"
and "when was this particular version selector last modified".

   or let versions be discoverable
   by adding an <allversions> tag to PROPFIND.

AKA a REPORT (:-).

Cheers,
Geoff

Received on Thursday, 21 December 2000 12:36:33 UTC