Subject: [Simple] XCAP and Webdav (was: XCAP batching)

From: Rohan Mahy <[email-masked]>
Date: Wed, 11 Jun 2003 16:51:02 -0700

Hi Folks,

I had a side conversation with Lisa Dusseault today (one of the 
co-chairs of Webdav) about the XCAP batching thread.  Here are her 
comments.  Please keep here cc:ed on this thread since she does not 
follow the SIMPLE list.

thanks,
-rohan

-----------

>> During the interim, we talked about using webdav. The idea there was
>> to first have the client LOCK the document, then perform a series of
>> changes (PUT, POST, DELETE), and then UNLOCK. AFter the LOCK, all of
>> the modification requests could be pipelined. The overhead here is
>> probably pretty small, since HTTP has few mandatory headers.
>>
>> I looked into webdav, and ran into the following issues:
>>
>> 1. Webdav doesnt specify a read lock. We would need to standardize
>> that in order to use it.

Why would you need read locks?  Clients who are simply reading the buddy
lists should just continue to be able to read it until the change (set 
of
changes) is made.

>> 2. The document would need to support a bunch of other webdav
>> operations, such as PROPFIND. You cant JUST do locking. You dont need
>> all of webdav, though.

Might as well use all of WebDAV tho -- I believe you could use an
out-of-the-box WebDAV server or server library, including
  - Alphaworks DAV4J,
  - Apache 2.0 which includes mod_dav
  - Microsoft IIS
  etc

That is, if the design is done right, the server where buddy lists is 
stored
may not need any new code.  If the server is also a IM server, the IM 
server
could simply tack on the WebDAV component using an extra servlet (the
alphaworks dav4j approach) or cgi module (the mod_dav approach).

>> 3. There is no rollback or versioning. So, if there is an intermediate
>> failure, there is no easy way to go back. We could fix that by
>> introducing versioning into webdav.

Uhh, versioning was standardized in WebDAV already -- RFC3253.  The 
'core'
versioning module is probably all you'd need for "an easy way to go 
back".
At any rate, intermediate failures are not a common problem in Web site
authoring because if a HTTP server does not receive the full body it 
doesn't
save it.

>> We can enable batched operations by defining a piece of the URI
>> namespace thats a "scratchpad". Documents in this area can never be
>> read directly by anyone but the document owner. To make a bunch of
>> changes, the client would COPY (using webdav copy) the document into
>> the area, using a random filename as the target. It then makes the
>> changes using a series of PUT/POST/DELETE, with pipelining. When done,
>> it performs a Webdav MOVE to place it back into the right place. We
>> can specify some rules for the server on only allowing a move of a
>> dcument back to the place where it was copied from.

Yes this is completely feasible.

>> I *think* we can support MOVE and COPY (and the additional webdav
>> headers) without all of the rest of webdav, but I would need to
>> confirm that. I didnt find any words that said MOVE or COPY can be
>> applied to a non-webdav resource.

You might want to support LOCK too.  LOCK the original document, COPY 
it to
the 'scratch' file, make changes, COPY it over the original (to avoid
overwriting the original's version history), DELETE the scratch file, 
UNLOCK
the original.  If this sequence is followed by all clients then scratch
documents can be used in combination with locks to advertise to other
clients that somebody is currently working on the document.

Note that this 'scratch' document functionality is standardized as a
"working resource" in RFC3253 which extends WebDAV.  This is an optional
feature but easy to implement -- the working resource feature.

(And you'd probably still want 'the rest of webdav' because PROPFIND at
least is needed to see document changes, etags, lock tokens, etc. 
PROPPATCH
and MKCOL may not be strictly necessary but they're not hard either.)

>>
>> If any intermediate operation should fail, the client just DELETEs the
>> document from the scratch area, and the original remains as it was. We
>> would also probably want to have documents in the scratch area expire
>> automatically after some time, so as to cleanup from incomplete
>> transactions.
>>
>> Assuming it is possible to MOVE or COPY non-webdav resources, my
>> current preference is for option IV.

Why are non-webdav resources involved in the MOVE or COPY?  Why 
wouldn't the
scratch file as well as the official file *both* webdav resources?  But 
to
answer the implied question, the specification doesn't forbid making a
non-WebDAV HTTP resource the _destination_ of a MOVE or COPY.  Since the
MOVE or COPY request is sent to the source resource, by supporting MOVE 
or
COPY the source resource implicitly supports WebDAV and therefore is a
WebDAV resource.

Overall, I'm still confused by the level of complexity being considered
here.  Perhaps WebDAV/authoring seems more complicated than it really 
is.
Here's how I'd suggest proceeding:

1. Define a WebDAV collection to be the buddy list location.
2. Define a main/default file for the buddy list.  This file might be
identified through a standard property on the collection.
3.Define other files for different 'profiles' (buddy lists with 
different
rules for different devices).  Again these could be identified as real 
buddy
lists through a WebDAV property on the collection.
4. Place all the internally-consistent information within an XML format 
as
the body of the WebDAV buddy list file.  If the block and allow lists 
must
be changed together (when adding from one and removing from the other) 
then
put them in the same file.
5. To change the default buddy list, or any profile buddy list, the 
client
does a LOCK, GET, PUT, UNLOCK.  As soon as the PUT occurs the new buddy 
list
is visible to other clients but since the whole file is internally
consistent this is great.
6. If integrity is a concern, require support for the standard MD-5 
header
as well, so that the client can confirm the server's signature for the 
file
as stored.  Alternatively, require support for the DeltaV/RFC3253 core
package and the working resource package, then you can do CHECKOUT, PUT,
CHECKIN (with or without LOCK/UNLOCK) to edit a buddy list.

None of this requires any protocol elements that aren't already 
standardized
-- just a new property or two, and a new XML format for the body of each
buddy list or profile.

Lisa

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple