Re: Why MD5 Headers are Imperative

Sorry, it's not that easy to wave your magic guru wand and dismiss me.

Here's what I have:  Atom Entry Documents are my basic unit of storage.  They 
are stored in one big, "flat-node" heap which exists on the HD as atom.dbxml. 
That file is managed by Berkeley XML DB.  We have written a servlet which 
transforms the public-consumption elements within <entry> nodes and exposes 
them at a unique URI similar to the Atom ID structure.

You keep telling me that my representation must be exactly equal to my 
resource, so I think you're the one who needs to go brush up on his reading. 
In general, this group tosses around the notion that my implementation must 
allow either APP or WebDAV to GET, PUT and DELETE the entire atom.dbxml 
resource.

-EJB

>-----Original Message-----
>From: Joe Gregorio 
>[mailto:joe.gregorio-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx]
>Sent: Thursday, August 17, 2006 05:28 PM
>To: eric-MkmoNbc1SAncr/OS1auqaA@xxxxxxxxxxxxxxxx
>Cc: 'James M Snell', atom-protocol-O6w3ZxSwtmQ@xxxxxxxxxxxxxxxx
>Subject: Re: Why MD5 Headers are Imperative
>
>On 8/17/06, Eric J. Bowman <eric-MkmoNbc1SAncr/OS1auqaA@xxxxxxxxxxxxxxxx> 
>wrote:
>> Here's the logical fallacy in the APP:
>>
>> "Once  a  resource  has  been  created  and  its  URI  is  known,  that  URI 
>>  can be  used  to  retrieve,  update,  and  delete  the  resource. "
>>
>> This asserts that the edit representation MUST be identical to the _resource_
>> and this is where you guys just lose me!  The Member URI may be used to 
>> update and delete the resource, but it will only ever retrieve a
>> _representation_ of the resource.
>
>"You keep using that word. I do not think it means  what you think it
>means." [1]
>
>Please read for a good overview of what resource, representation, and URI mean:
>
>  http://www.w3.org/TR/2004/REC-webarch-20041215/#id-resources
>
>
>[1] http://www.imdb.com/title/tt0093779/quotes
>
>   -joe
>
>-- 
>Joe Gregorio        http://bitworking.org
>