Thanks for the patch, I have couple comments : When reading a simple feed, should I get an eTag back ? Below are the HTTP Headers I get back when reading the customer collection from the consumer/provider tests.
http://localhost:8084/customer GET /customer HTTP/1.1 Host: localhost:8084 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080707 Fedora/2.0.0.14-3.oc2 (CK-IBM) Firefox/2.0.0.14 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.9,zh;q=0.7,zh-cn;q=0.6,zh-hk;q=0.4,zh-sg;q=0.3,zh-tw;q=0.1 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cache-Control: max-age=0 HTTP/1.x 200 OK Content-Type: application/atom+xml; charset=utf-8 Transfer-Encoding: chunked When reading an entry, it looks like we are using the entry id as eTag. In the case where a customer field gets updated (e.g customer phone), what would be the entry eTag ? http://localhost:8084/customer/urn:uuid:customer-6257dac0-616a-488f-8ad9-53942529a6b8 GET /customer/urn:uuid:customer-6257dac0-616a-488f-8ad9-53942529a6b8 HTTP/1.1 Host: localhost:8084 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080707 Fedora/2.0.0.14-3.oc2 (CK-IBM) Firefox/2.0.0.14 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.9,zh;q=0.7,zh-cn;q=0.6,zh-hk;q=0.4,zh-sg;q=0.3,zh-tw;q=0.1 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive HTTP/1.x 200 OK Content-Type: application/atom+xml;type=entry Etag: "urn:uuid:customer-6257dac0-616a-488f-8ad9-53942529a6b8" Last-Modified: Sat, 02 Aug 2008 00:07:25 -0700 Location: urn:uuid:customer-6257dac0-616a-488f-8ad9-53942529a6b8 Transfer-Encoding: chunked After we have a more dynamic eTag, I think we also need to update the test cases to make sure some iterative scenarios are working : - Read a feed for the first time, read a second time passing the eTag received and make sure we get a 304 HTTP Status code. - Read a entry, read a second time passing the eTag received and make sure we get a 304 HTTP Status code. - Read a entry, update a entry, read a second time passing the eTag from the first read and make sure we get the updated entry and not a 304 HTTP Status code. - etc On Thu, Jul 31, 2008 at 1:04 PM, Dan Becker <[EMAIL PROTECTED]> wrote: > Luciano Resende wrote: >> >> On Tue, Jul 22, 2008 at 1:22 PM, Dan Becker <[EMAIL PROTECTED]> >> wrote: >>> >>> Jean-Sebastien Delfino wrote: >>>> >>>> Dan Becker wrote: >>>>> >>>>> One item that has been published in the Tuscany future roadmap >>>>> (http://tuscany.apache.org/sca-java-roadmap.html) is the need for Atom >>>>> binding etag and server sided caching support. JIRA TUSCANY-2447 has >>>>> been >>>>> opened to track this feature. >>>> >>>> I think it would be useful to: >>>> 1) build a scenario to help us explore what the app developer needs to >>>> write (like Luciano's photo gallery or a simple customer info data base >>>> for >>>> example) >>>> >>>> 2) study and compare how others (popular REST APIs, ATOM implementations >>>> and content management systems) expose etags / if-modified to >>>> application >>>> developers. >>> >>> Thanks for the guidance Sebastien. Now, a few questions for the developer >>> group. >>> > > > ETag and Last-Modified feature provided as a patch to TUSCANY-2477. > > As we discussed here, one predicate that was not supported was the If-Range > request on feed entries. This would be a useful feature for future as is > would limit the response body size on large feed collections. > > > -- > Thanks, Dan Becker > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
