RE: Working Resource Issues ...

   From: John Hall [mailto:johnhall@evergo.net]

   > ... so it would need to be a 
   > really glaring flaw for us to add/change the protocol at this 
   > point (deletion is still fair game, though).

   How do you determine glaring flaw?  It meets my definition, and the
   use case is not unheard of if you are sympathetic to servers that
   don't want to support UPDATE.

I am sympathetic to servers that don't want to support UPDATE, but the
working group as a whole was not, so the update feature was made part
of the client-workspace package.  The consensus of the working group
was that making the body and dead properties of a VCR be a copy of
those of an arbitrary version was too simple to implement to be an
obstacle for a basic versioning server.  I had no real
counter-argument to that statement, which is why update stayed as part
of the client-workspace feature.  So you would need to provide some
compelling argument for why it would be hard to implement.  "My users
don't want it" would not count as a compelling argument, since we're
talking about compromises to achieve interoperability, and your users
would not be forced to use this functionality, but your server is
forced to provide it to be interoperable with those clients written
for users that do want that functionality.

   > How do users see "their" checkouts?  We don't want to tie the 
   > versioning protocol to some kind of authentication mechanism.

   Same way you do for WORKING-RESOURCE -- by responding with a Location
   record.

I misunderstood what you were proposing.  I thought that you were
proposing some new mechanism that didn't involve allocating new URL's
for the working resource (the word "invisible" led me to believe
that they did not get a URL).

   > You'd have to also define how every other HTTP method acts 
   > against these "invisible" resources.  What about MOVE, LOCK, 
   > COPY?  (This would make even lock-null resources look good in 
   > comparison :-).

   Well, the spec doesn't define how a checkout-in-place works against
   these verbs, either.

If the "invisible" resources get a URL just like a working resource,
then I agree that there is no problem with defining MOVE, LOCK,
and COPY semantics.  I thought that you were proposing that somehow
the server would know that the user had performed a checkout, so
that when the user applied a method to the VCR, the server would
retarget that method to the "invisible" checked-out resource.
Apologies for the misunderstanding.

Cheers,
Geoff

Received on Saturday, 23 June 2001 23:18:54 UTC