RE: DELETE leaving a lock-null resource; was LOCK Scenarios

Sigh... I have had to delete a lot of WebDAV mail recently unread. WebDAV is
no longer the focus of my existence and my other duties are pressing so it
is difficult for me to properly contribute to these conversations. I will
throw in a few points of general experience that I hope will help:
<jra>
Too bad, your participation will be missed.
</jra>

1) I guarantee that if you change the way LOCK works you will end up with a
protocol that will be unimplementable on the majority of existing systems.
The namespace is locked by a LOCK request for a damn good reason, if you
change it, most of us implementers will probably just be forced to ignore
you so we can properly support our users.
<jra>
The issue of namespace control and resource contents control are separate.
Namespaces are the domain of collections. If a user wants to control a
namespace, then the collection managing or defining that namespace can be
(shallow) locked. Multiple bindings and versions introduce new locking problems
which we have to address. Some of these issues may require us to go back and
rethink existing semantics.
</jra>

2) A link to the history resource should never appear to a down level
client, they should only see a URL to a tip version. If this is not the case
with the version design then the version design is broken.
<jra>
non-versioning aware clients will see revisions selected by the default
workspace. Tip revisions alone would not provide any way for a site
administrator to provide a consistent set of revisions to these clients.

non-versioning aware clients can access all unversioned resources, including the
history resource and interpret the contents any way they want. It might not be
useful, but there's really no need to prevent it.
</jra>

3) MOVE doesn't move locks due to interoperability issues. If you want a
protocol no one but a couple of super high end providers can ship then go
right ahead, make the change.

The problem here is that the people really working hard on this protocol,
folks like Geoffrey and JimA, are basically super high end people. They are
not used to having to live in the crappy, confined, miserable, limited hell
known as consumer software. Therefore they make proposals which are 100%
consistent, elegant and imminently reasonable, if you are shipping a super
high end system.
<jra>
I have to strongly differ Yaron. Geoff and I have both consistently pushed for
simplicity and elimination of design by special case. Elegant, simple, useable,
and implementable go together. The process of getting there is MUCH harder.
</jra>

Asad and I used to represent the dirty masses and I did a good pitch at
representing clients (having worked on IE for all those years) but no one
seems to have taken our place. The discussions here are very far removed
from the reality of consumer software. You are creating a standard that will
only be implementable on brand new, high end systems. Existing users will
simply be screwed. WebDAV's current success has been that 2518 is easy to
implement. The stuff you guys are creating and the changes you are proposing
to 2518 to allow you to implement your super high end features will kill the
lower end market.
<jra>
WebDAV will continue to be a layered protocol with lots of options. Server
implementors will have lots of freedom to provide simple support, or extended
functions for users that need them. Adding bindings and versioning does not
require all server vendors to implement them.

B.T.W., there's lots of client activity going on based on the versioning
extensions, and these extensions are based on many existing client applications
and use cases. So I don't agree that we are so far off the mark.
</jra>

Received on Friday, 24 September 1999 16:08:14 UTC