Atomic Delete and reflecting implementation details in the protocol

Just a couple of thoughts on the atomic delete issue. What interests me
most is the ability to leverage WebDAV as a standard protocol for mapping
multiple client applications to multiple repository managers. This is what
interoperability means. In the interest of maximizing the number of
available clients, it might also be useful to consider other protocols as
candidates for this mapping, in particular the clients that already use
these protocols. Managing this many-to-many association cannot be done
without work. WebDAV provides us with a place to do this work, but doesn't
eliminate it. Knowledge about existing repository managers, file systems,
and existing protocols will help us minimize the work required for
integration, but also won't eliminate it. There will always be compromises
that must be made, and some of them may result in servers that have more or
less capability than others. When faced with conflicts, the WebDAV protocol
should focus on supporting use cases that have broad user value rather than
yield to the implementation details of a particular repository. This is a
balance that requires judgment, negotiation, and compromise. So while I
appreciate the fact that the Microsoft file system is the most common one
in use today, and that it doesn't support binding to collections or atomic
delete for good reasons, I don't feel that it is necessarily in the best
interests of the WebDAV community to simply adopt the NTFS file system
semantics as WebDAV semantics. It is not necessary to have a 1-1
correspondence between the underlying repository and WebDAV semantics. The
protocol provides a place to map the WebDAV model to the underlying
repository model. This layer will be thick or thin depending on the
magnitude of the differences in world views, but in my experience it hasn't
been that difficult to build. It is the opportunity to do this work that
gives WebDAV its greatest value, not necessarily its ability to avoid the
work.

As far as delete is concerned, I think delete should simply remove a
binding from its parent collection. If there are no other bindings, the
server is free to garbage collect or not. If there are other bindings, then
they will still work as expected. The protocol does not expose the
difference between "real" internal members and bindings. The real resources
are only accessible through bindings, and are never accessed directly
through the protocol. So it seems to me that delete can always be atomic as
it only ever deletes one thing. How, when, and if the garbage is collected
is not visible to clients, and since candidates for garbage collection have
no other bindings, clients can't access them, and it doesn't matter when
they are deleted. How a server maps bindings to its underlying store is
also not visible to clients. This could be a simple reflection in the file
system, or use a relational database, or do different things for different
resources if the WebDAV server supports multiple repository managers.
Relying on a 1-1 correspondence between WebDAV resources and a
manifestation in the file system would seriously limit WebDAV's appeal.

If a repository manager supports multiple protocols, and the protocols are
not done through protocol translators to WebDAV or some other common
protocol, then a conflict between the protocols could arise. It is the
responsibility of the protocol implementers on the shared repository to
resolve these conflicts. We cannot reflect them back up into the WebDAV
protocol as this would couple the protocol with a particular repository
implementation which would in turn limit interoperability and WebDAV
adoption.

Received on Tuesday, 1 February 2000 16:08:25 UTC