RE: WebDAV and disconnected/asynchronous operation

  Mike Evans writes:
  I need to know if any work is currently being conducted into using WebDAV
over slow/intermittent connections?  From what I have read from the
archives, the discussion on this topic seemed to end in 1997, with a small
discussion on 'email access to DAV functionality' and 'disconnected
operation', but I can't find any outcome to these discussions.  Was any
decision reached to include/preclude such operation in the spec, or was it
decided to leave it to specific impementations to handle in their own way?

The final decision was to design the specification in such a way that
someone could come back later and add email access if they desired (to date
no one has done this).  The concern at the time was that some large fraction
of the Internet only had intermittent access, and would not be able to
access WebDAV functionality if it were limited to HTTP. The designers of
WebDAV didn't agree with this assessment, since while the protocol was being
developed there was an increasing trend towards higher modem speeds, and
high speed access.

However, it still seems quite possible to add in email transport for WebDAV
operations. One approach is to package up WebDAV requests and responses as
message/http MIME messages (defined in the HTTP specification), and email
them from client to server.

Note that email access and disconnected access aren't the same thing. WebDAV
has the potential for being used in a disconnected manner using HTTP.  One
scenario is for a client to connect to the server, perform a
LOCK/PROPFIND/GET sequence, then completely disconnect.  The lock stays
active during this time, since locks are not associated with network
connections.  Then, when the client is ready to finish, it reconnects, and
does a PUT/PROPPATCH/UNLOCK sequence.

I'm not sure what affect an intermittent connection would have. WebDAV, like
HTTP, assumes it is running over TCP/IP, which is a reliable transport. An
intermittent connection suggests that the connection isn't reliable.  I
suspect the best place to solve this is below the application layer.

  To give you some context, my Ph.D work is centred around managing
information on the web. Hardly new, I know, but part of the work is based on
developing a resource migration mechanism for the web.  Before you all
switch off, I am currently designing a resource migration protocol that
manages the migration process, with WebDAV being used to handle the physical
movement of the resource across servers during a migration.  The idea is
that an agent manages the process on behalf of a client.  The client could
be a user, or a programmatic client (such as a distributed object).  If it's
the latter, it will need to send a 'Migrate' message to the agent (which
could be on a different host to the client), and wait for the response.
What concerns me is the potential delay in receiving this response.  The
migration process comprises several DAV commands, some authorisation along
the way, and the updating of a suitable name service, which could
potentially take some time.  Waiting for the response may not be a good
idea, but I'd hate to go ahead and implement my own asyncronous operation if
it conflicts with what has already been developed (and why reinvent the
wheel anyway?!)

I suspect there is some overlap between Web site migration, and cache
replication (in both you are trying to duplicate a Web site) -- there is
some discussion of cache replication protocols in this Internet Protocol
Journal article:
"Web Caching"  Geoff Huston
http://www.cisco.com/warp/public/759/ipj_2-3/ipj_2-3_webcaching.html

Due to the time involved to perform the 'migrate' operation, I think you're
right, typical remote procedure call semantics aren't ideal, since there is
too large a time between request and response.  What you'd like to do is
send off the request, and receive an asynchronous event notification once
it's completed.  Unfortunately, there is currently no generic event
notification protocol standard, although plenty of work has been done on
this topic (see http://www.cs.caltech.edu/~adam/isen/event-systems.html for
a survey of 144 of them).

  Could anybody inform me, therefore, if any work has been carried out into
disconnected operation, as I will gratefully use it.  If not, I'll have to
come up with my own solution. Clearly, as I'm working on automatic operation
of the migration process, I can't use e-mail notification.

Well, email doesn't necessarily preclude automatic handling.  You could have
an email sent to a particular address, and have email to that address
handled by a program, not some email user interface.

  BTW, I was wondering what (if anything) I should do with the migration
protocol once it's complete? The protocol _uses_ WebDAV, it doesn't _extend_
it, but it does extend HTTP (minimally), and it does define cross-server
operations, so it may be useful to others.  Should I write an Internet
draft? Would it be useful to this group? If not, who would it be useful for?
(the IETF and W3C seem a bit quiet on the resource migration front, and the
URN group seems a bit contentious! Would they welcome such a draft?).
A detailed description of using WebDAV to perform Web site migration would
be a useful document for others to read.  Since it doesn't sound like you're
adding much protocol mechanism, this would likely end up as an Informational
(not standards track) RFC.  But, once you've written it up, it would be much
easier to see what trajectory it should take.

- Jim