RE: Confusion: Removing a resource from version control

I believe we actually have a reasonable compromise on this particular
issue, but Lisa does raise some interesting points below that I
thought were worth following up.

   From: Lisa Dusseault [mailto:lisa@xythos.com]

   > A versioning aware client needs to do what the versioning aware
   > user wants (not just some random behavior selected by a
   > versioning server implementer).

   It seems to me that this is an inconsistent position with respect to
other
   implementor-dependent behaviour already allowed by DeltaV.

Yes, DeltaV does allow the server implementer some choices,
but only after a great deal of effort to find an acceptable
common semantics.  So this does appear, but only as a last
resort after all reasonable effort has been expended to determine
an alternative.  A key factor in allowing such choices is how
significant the impact of this choice is on the user.

   You might also say "A versioning aware client needs to do what the
   versioning aware user wants (not just some random behaviour
   selected by a versioning server implementer).

Actually, that is what I said (:-).

   So that means if the versioning aware user wants the resource to be
   created as a regular resource, the versioning aware client needs to
   somehow be able to create the resource as a regular resource.

Yes, this was one of those choices.  In this case, the consensus was
that the impact on the user of automatically putting something under
version control was minor, compared for example, to the impact of the
server automatically deleting a resource the user wanted to preserve.

   Similarly, if the versioning aware user wants the resource to be
   created as a version-controlled resource, the versioning aware
   client needs to somehow be able to achieve that."

   Yet, the deltaV specification allows implementations to create
   resources that are versioned in response to a PUT to a
   non-existent, or to create resources that are not versioned.
   That's "some random behavior selected by a versioning server
   implementer."

Having the server "not support" something is inevitable.  The issue
is whether a method that is supported has consistent semantics from
server to server.

   I could probably come up with some more examples!

All such examples should be highlighted in the protocol with the
presence of the MAY keyword.  I believe we have debated at great
length over all such MAY semantics but if there is one that you feel
should be eliminated, please feel free to raise it as an issue.

Cheers,
Geoff

Received on Wednesday, 13 June 2001 22:59:00 UTC