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

From: Adam Roach <[email-masked]>
Date: Thu, 12 Jun 2003 10:49:44 -0500

Lisa Dusseault wrote:

> 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 listis visible to other clients but since the whole file
> is internally consistent this is great.

The issue is that XCAP is specifically being defined so that you don't
have to PUT the entire document. In a nutshell, it uses XPATH syntax
to specify a subset of an XML document to be updated.

Consequently, there's a need to be able to lock a whole document,
perform *several* updates on subsections of that document, and then
unlock the whole document. Until the final update, the document is
not typically in a consistent state.

So, the two approaches that have been mentioned so far are:

 1) Prevent reading while a document is locked for writing
    (except, obviously, by the client who has the document locked).

or:

 2) LOCK the document, COPY it somewhere that others won't try to
    access it, perform multiple updates on the temporary copy, COPY
    the temporary document back to its original location, and UNLOCK
    the document. It's a bit chatty, but it doesn't require any
    modifications to existing WEBDAV servers.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Jun 2003 16:17:12 -0400

> not typically in a consistent state.

Right. To hammer this home - we are specifically managing things like 
authorization policies, where an intermediate state might represent 
something truly undesirable. We absolutely MUST have the document only 
read by presence servers when it is in a consistent state.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Jun 2003 16:17:12 -0400

-Jonathan R.

---

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 12 Jun 2003 10:15:56 -0700

Sure, but why wouldn't you use XPATH to change pieces of the document on the
client side then send the whole thing back to the server?  Over Internet
latencies with files this small, this is likely to be faster for the user
anyway.  Then the protocol needn't bother with this complication.

I really don't understand why partial PUT is necessary, but if it is, I
would recommend the following (and you would likely get support or
assistance from other WebDAV implementors in defining and developing this):
 - Define a MIME type for an XPATH-based modification to an XML document.
Perhaps this MIME type exists already -- a stylesheet type? 
 - Define a method like PATCH or PUTPATCH to send this document to the
resource to be modified
 - Beyond this new mechanism, simply use HTTP GET/PUT/DELETE, and WebDAV
PROPFIND/MOVE/COPY/LOCK/UNLOCK, and possibly the DeltaV CHECKOUT/CHECKIN to
create a working resource in a 'sandbox' while the PATCHes are applied.

A patch or "partial put" mechanism has been discussed in WebDAV circles for
a long time, and only other work has prevented us from proceeding on it.
Generally the idea is to have a byte-oriented diff mechanism that isn't
limited to XML -- one that can be applied to text documents, images, etc.
However, much of the same work would need to be done.  For example, a PATCH
method could be defined that took a couple of different MIME types depending
on what mechanism is used to patch the target file.  

Lisa

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]] 
> Sent: Thursday, June 12, 2003 8:50 AM
> To: 'Rohan Mahy'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Simple] XCAP and Webdav (was: XCAP batching)
> 
> 
> Lisa Dusseault wrote:
> 
> The issue is that XCAP is specifically being defined so that 
> you don't have to PUT the entire document. In a nutshell, it 
> uses XPATH syntax to specify a subset of an XML document to 
> be updated.
> 
> Consequently, there's a need to be able to lock a whole 
> document, perform *several* updates on subsections of that 
> document, and then unlock the whole document. Until the final 
> update, the document is not typically in a consistent state.
>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 12 Jun 2003 10:15:56 -0700

Lisa