W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

RE: WebDAV Bindings - Issue Yaron.AtomicDelete

From: <ccjason@us.ibm.com>
Date: Wed, 19 Jan 2000 15:55:45 -0500
To: Fisher Mark <fisherm@tce.com>
cc: w3c-dist-auth@w3.org
Message-ID: <8525686B.00730974.00@D51MTA03.pok.ibm.com>

That's the key point here.  On a direct-mapped webserver (no alias support
in the webserver) that uses a singly-linked filesystem like VMS or
Win32API-NTFS as a WebDAV backing store, it may make sense for the DELETE
actually remove the underlying file.

Yes.  The files can be deallocated as long as the other requirements are
And yes, it might be the right thing to do for a given server.  But WebDAV
currently agnostic on that topic.  A server it free to do that as long as
stick to the requirements that the proposal outlines.  So what are those
requirements that need to be fulfilled?

If the server supports multiple bindings, it definitely it must not remove
any links/resources that
are also accessable via another binding.   If they aren't accessable via
any other binding, then whether
they get removed or not is not something a client can currently detect so
the server has a bit more flexibility.
The only other constraint then is that the server not delete from bottom
up, run into a problem half way and
leave the job half done.  If you can meet this requirement, you can feel
free to deallocate all those files.

As for a server that doesn't support multiple bindings, we don't have a
strict requirement except the desire
for consistant and predictable behavior across all servers.  I doubt any of
us want to actually have
two classes of servers out there that have *very* different behaviors for
the same operation.  As I think I've
tried to point out, even the singly-linked repositories that we've
discussed to date can meet these
requirements.  It is my hope that we all can settle on this one DELETE
semantic for all servers.

As for us all settling on one semantic.  The webdav model is not an exact
match of any existing repository
that we know of right now.  Some lack depth locks.  Some don't have URI
protection.  Some only have
cooperative locks.  Some don't have multiple bindings.  Some don't support
loops in their bindings.  Some
don't have strong bindings to collections.  Some have features that can't
easily be exposed.  We all
will have our own difficulties implementing any useful spec over each of
our existing systems.  Sure we could
dumb down that protocol, but we'd be left with an FTP look-alike.   Sure we
could let the spec fragment, but that
would limit the value of our work.  We've chosen to come up with something
that's both functional and
interoperable.   That means that everyone will have to bend to deal with
impedance mismatches between the webdav model and the model that their
repositories use.  But if we are all
willing to do our share of bending, we as a community will really be
delivering something of value to the
internet community.

Received on Wednesday, 19 January 2000 15:57:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:21 UTC