RE: request for un-version-control feature

   From: Julian Reschke [mailto:julian.reschke@greenbytes.de]

   > From: Clemm, Geoff
   >
   > The main part of the question was:
   > "Could you motivate the need to unversion-control a resource."
   > The fact that "two implementations want to do it" is not the
   > most compelling answer (there are lots of things that you could
   > get two implementations to agree on that would not merit
   > adding to a standard protocol).

   Well, if there are multiple implementations that want it, it's
   certainly nice if you can marshall it.

New standard protocol features do not come for free ... they introduce
additional complexity into the protocol, especially for client and
server implementations that try to fully implement the protocol (to
maximize interoperability).  So I believe it is reasonable to at least
require a compelling use case (and even that is not sufficient, when
there is not agreement on how to handle that use case, e.g. the
rejection of the Translate header).

   Regarding the what-is-the-need-question: it makes a difference
   whether you are building a new system that accurately reflects the
   deltaV model, or if you are using deltaV to HTTP-marshall requests
   between systems that exist independantly of WebDAV. In the latter
   case, you really can't choose -- you'll have to come up with a way
   to marshall that type of request (or you'll have to live with an
   unhappy customer).

If you included in the standard every feature provided by any system, 
the protocol would be unusably complex, and would provide no basis
for effective inter-operation.  So every system will have a set of
non-standard features and extensions that it supports.  Only ones that
are considered widely needed will end up in the standard protocol.

   In general, I understand why a system would version everything, or
   a system where the decision about what is version-controlled is
   made by the server.  What I don't really see is the use case for a
   system that has an explicit "enable" but no "disable" call.

The burden of proof is on the proponent of a new feature.  A new
feature is accepted because you have convinced people that it is
useful/necessary, not just because nobody demonstrated it was not
useful.

Note that there are use cases for deleting the history of a resource
(which is marshalled by issuing a DELETE request against the
version-history resource).  What has not been demonstrated is the need
to "disconnect" a resource from its history without deleting the
history.

Cheers,
Geoff

Received on Friday, 14 February 2003 15:18:00 UTC