Re: Some thoughts on XCAP's resource architecture

Lisa Dusseault wrote:
> 
> We're actually on the same page about granularity.  HTTP does not 
> *define* a specific granularity, as you said (and as others have pointed 
> out, many HTTP implementations are capable of handling a very small 
> granularity).  However since HTTP is one of the most widely deployed 
> protocol systems we have, where browsers and intermediaries interact 
> with a wide variety of servers and not just one host server, the 
> practice matters as well as the definition.  And the extensions that 
> have been written to HTTP most definitely assume a larger granularity.
> 
> I thought of another way to describe the resource granularity problem.  
> When we say that something is "An HTTP Resource", here's what we imply 
> (particularly for static, authorable resources):
> A resource can be queried for the current Entity Tag if the server 
> supports ETags.
> A resource has its own last-modified timestamp, and supports the 
> If-Modified-Since and If-Unmodified conditional headers.
> A resource has a Content-Type and a Content-Length, and may have an 
> entity Digest (Content-MD5)
> A resource may be cacheable.

Nit: it's not the resource that has etags and such, it's the resource's 
variants. The assumption that each resource has only a single variant in 
general is incorrect.

 > ...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 24 November 2004 22:01:27 UTC