RE: ETags and concurrency control

[Pablo Castro <Pablo.Castro@xxxxxxxxxxxxx>]

It looks like the other fork of this thread went deep into week ETags in particular, which I'd love to see that we sort out... :)

Regarding this:
>> From: Teo Hui Ming [mailto:teohuiming.work@xxxxxxxxx]
>> AtomPub (Section 10) AFAIK, requires client NOT to assume a collection
>> feed contains full-representation entries. So, even if client
>> retrieves a feed of SalesOrder entries, client still need to retrieve
>> individual entry separately for editing purpose (therefore, it will
>> get entry's ETag HTTP header). As a result, embedded entry's ETag lost
>> its purpose.

>> A workaround discussed in [1] is to explicitly label collection feed
>> as 'full-content' feed, and require clients to check against the label
>> every time before it can assume the feed is full-content. For Astoria
>> use case, is it worth to workaround AtomPub's section 10 requirement
>> with two new extensions (full-content label + embedded entry etag)?

>> [1] http://www.imc.org/atom-protocol/mail-archive/msg10630.html

This is a good point. It's too bad that there is no standard one of annotating an entry as "complete", as it renders the annotation almost useless (if you know what exact server implementation you're talking to in order to look for the "complete" marker, maybe you can also know that collections always carry complete entries...). The approach of using a <link> element seems overkill. Now, details around the actual annotation aside, this makes sense. I'll see if we can modify our entries to have some form of "complete" marker to address this particular concern.

-pablo


-----Original Message-----
From: Teo Hui Ming [mailto:teohuiming.work@xxxxxxxxx]
Sent: Thursday, April 24, 2008 7:07 PM
To: Pablo Castro
Cc: atom-protocol@xxxxxxx
Subject: Re: ETags and concurrency control

On Fri, Apr 25, 2008 at 8:19 AM, Pablo Castro
<Pablo.Castro@xxxxxxxxxxxxx> wrote:
>  ETags in headers versus body: whenever we return a resource that represents a single underlying entity, if the entity has ETag-annotated properties we include an ETag response header. However, there are times where a URL points to a resource that's a list of other resources/entities (e.g. /Customers(123)/SalesOrders returns a feed with an entry for each sales-order resource for a given customer). In those cases returning an ETag in the header wouldn't help a client that will need to update a single one of those entries later on. So we include the ETag for each entry in an attribute in the entry element. I wonder if there is prior art for this...

AtomPub (Section 10) AFAIK, requires client NOT to assume a collection
feed contains full-representation entries. So, even if client
retrieves a feed of SalesOrder entries, client still need to retrieve
individual entry separately for editing purpose (therefore, it will
get entry's ETag HTTP header). As a result, embedded entry's ETag lost
its purpose.

A workaround discussed in [1] is to explicitly label collection feed
as 'full-content' feed, and require clients to check against the label
every time before it can assume the feed is full-content. For Astoria
use case, is it worth to workaround AtomPub's section 10 requirement
with two new extensions (full-content label + embedded entry etag)?

[1] http://www.imc.org/atom-protocol/mail-archive/msg10630.html

--
Teo Hui Ming