W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2004

Re: Some thoughts on XCAP's resource architecture

From: Joe Gregorio <joe.gregorio@gmail.com>
Date: Mon, 22 Nov 2004 18:25:14 +0000
Message-ID: <3f1451f504112210253425433a@mail.gmail.com>
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: HTTP working group <ietf-http-wg@w3.org>, "simple@ietf.org" <simple@ietf.org>

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 Gregorio        http://bitworking.org
Received on Monday, 22 November 2004 19:52:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:38 UTC