Re: [Simple] Some thoughts on XCAP's resource architecture

Jonathan Rosenberg wrote:
> >1a) HTTP intermediaries and scaling: caches aren't designed to cache 
> >huge numbers of tiny resources.  It would probably be wise to disable 
> >caching on XCAP responses.
> 
> This is described in section 9 of xcap, which more or less says that you 
> will want to disable caching for dynamic resources - ones frequently 
> written by clients or otherwise. However, there are application usages 
> where the data is primarily read-only. In that case, its reasonable to 
> allow caching of those resources.
> 
> As such, there is an interaction with xcap and caching, but not because 
> the resources are small - because they may be dynamic. This is an issue 
> for any http resource.

xcap resources may overlap, and that means they share content.  This
content has to be duplicated in the HTTP caching model, and that is a
sense where some usages don't scale optimally.

It would be hard to design a caching model which did scale optimally.

> Jamie Lokier wrote:
> >Lisa Dusseault wrote:
> >
> >>>If you have multiple changes to make to a 1 MB or smaller document, 
> >>>batch them up together if possible, even if it requires uploading the 
> >>>whole document afresh.  The current design of XCAP encourages changes 
> >>>to be made independently, and each change will require a full 
> >>>round-trip (no pipelining possible because you need to wait for the 
> >>>server to respond with an ETag each time).
> >
> >
> >That seems like a flaw which should be fixed.
> 
> I have to disagree with Lisa here, this is not a constraint on xcap. You 
> do not have to wait for the etag to send the next request. You only have 
> to wait for the etag if you wish your next change to be conditioned on 
> the fact that the document hasn't been modified since your last change. 
> That's true of http generally, and true here too - its the defining 
> purpose of the If-* headers. The various application usages talk about 
> ways in whcih the documents are structured so that one doesn't need to 
> used conditional PUts'. In that case, feel free to pipeline.

In other words, you can only batch a group of small updates when you
want to apply them unconditionally.

The usual way to update a resource where data should never be lost or
the update is logically an atomic data-dependent operation is to do
them conditionally, using If-* headers.

This works fine in HTTP for updating a single resource.

It also works fine in HTTP for updating parts of a resource, when
using the not yet standardised PATCH operation.

But with XCAP, when a group of small updates is to be applied
conditionally, then a round trip time will be incurred between each
small update.

This is very slow for many small updates.  Combining the updates to
simply write a large portion of a resource does not scale if it's a
very large resource and only small, sparse updates are required
(e.g. when updating an entry an an XML database).

The suggested workaround is to restructure the XML documents so that
updates are done unconditionally.

In other words, things like XML databases would be wrapped in some
kind of "front end" such that the view seen through XCAP doesn't
correspond directly with the tree structure of the underlying data
resource.  A transformed view allows unconditional PUTs to be
translated to atomic logical operations on the underlying data resource.

This seems to me to defeat much of the point of XCAP, which is to
remove the need for application-specific APIs for accessing and
updating data resource parts.

It is not hard to think up solutions which allow updates of many small
parts of an XCAP as one effective operation.

Because atomic updates are useful, it would make sense to do compound
updates in a single HTTP operation.  Merely finding a way to pipeline
the updates would _not_ be adequate.

The obvious methods are to define a compound update PUT form,
e.g. using multipart/something, or to propose an extension to XCAP
which uses PATCH.

It would be generally useful to have a PATCH format which is good for
updating parts of XML documents, but that is probably best left as
another engineering problem.

Meanwhile, a multipart/something PUT form would be quite easy to
define, and it could be an optional but recommended feature.

-- Jamie

Received on Sunday, 5 December 2004 17:20:53 UTC