Re: Some thoughts on XCAP's resource architecture

On Sun, 21 Nov 2004 18:58:47 -0800, Lisa Dusseault
<lisa@osafoundation.org> wrote:
> 
> During the DC IETF, I expressed some reservations about XCAP to Ted and
> Jonathan. Jonathan asked me to send a message to the SIMPLE list with
> my comments, so here it is...
> 
> Based on the mailing list on the traffic, it appears that  XCAP is
> supposed to be an extension or profile of HTTP, rather than just a
> protocol that mimics the HTTP interaction style, and that as such it is
> intended to be compatible with other extensions of HTTP.  I'm concerned
> that the current architecture of XCAP makes this difficult.  In
> particular the XCAP resource ontology and the URL addressing style that
> goes with it shifts the HTTP design along two major axes:
> 
> 1) Resource granularity
> 2) Dependency between resource
> 
> The first shift is in size and number of resources.  Because the path
> part of the URL allows for XML node selection, there are many more
> resources for a given volume of content material.  This affects us in a
> number of ways.

<Lots of granularity arguments elided>

This is just silly, HTTP is used to serve up everything from
100MB mpegs to a myriad of spacer GIFs. There is no such
thing as a 'regular level of resource granularity' on the web.


> 2)  Dependencies:  HTTP servers are designed such that static resources
> are handled independently of each other. Their ETag management is
> stand-alone, the request and response handling and concurrency are
> designed for that independence.  By contrast, XCAP contemplates a large
> number of resources which really map to parts of the same underlying
> file.  As far as I can tell, that introduces dependencies between
> resources (for example that a PUT to one URL would require the ETag of
> another URL to change).
> 
> 2a) HTTP implementation barriers.  The last HTTP server I developed
> would have to be rearchitected in several places to handle XCAP's
> interdependencies, work beyond what you'd expect from adding XCAP
> support.  Throughout the server, the code uses exact matching of URLs
> to figure out what to do -- not URL pattern matching. So for example:
>   - The way ETags were generated and stored and changed would have to be
> thrown out because ETags were generated independently for every
> resource.
>   - Since resources were independent, write requests for different
> resources could be handled concurrently with ease, but that would have
> to change.
> 

You are talking about implementation details, a choice on the part of 
the server writer. If you choose wrong, you may have 
difficulties, nothing earth-shattering there.

    -joe

-- 
Joe Gregorio        http://bitworking.org

Received on Monday, 22 November 2004 19:52:28 UTC