Re: Proposed HTTP SEARCH method update

["[e-mail]" <[e-mail]>]

> On 26 Apr 2015, at 11:17, Julian Reschke <[e-mail]> wrote:
> 
> On 2015-04-26 07:40, [e-mail] wrote:
>> ...
>> Great!  We are getting closer to the core of the problem, which I had tried to address earlier :-)
>> 
>> I agree that HTTP caching should operate upon representations of resource state. My point it that SEARCH always returns a partial representation of the resource state, so that it should be cachable too. This means
>> improving the caching stack so that it knows how to update partial representations.
> 
> And you seriously believe that people are going to upgrade their caching stack specifically for SEARCH?

I suppose you are talking about more difficult to change caching stacks like those deployed by ISPs or even countries. ( In 1994 I remember the UK had a country wide cache to help us get pages from the  USA faster ). Those caches will presumably only change when the need for it is strong enough. Luckily they don't have to change those services until they feel like it. 

What will happen immediatley though is that people like me and others on this list, will write  local JS caches for data using any of the numerous storage mechanisms available in browsers.  We will also write servers that can implement SEARCH for local and remotely proxied resources, as I have partly done here in Scala here

  https://github.com/read-write-web/rww-play/wiki/Curl-Interactions#sparql-queries

Some people may wish to implement SEARCH for XML query languages, other for CSV formats, others for JSON, etc. I'll be doing something for JSON-LD.

But we might as well write the spec for SEARCH in such a way that when the market grows enough that the large infrastructure companies will want to buy new enhanced proxies tuned for the languages that are most used ( probably nothing to do with what I am doing ) to improve the service for their customers, that these can then together with the stacks the initial group has deployed to satisfy their more limited needs.

> 
>> To illustrate the different cases, let us take the example from http://datatracker.ietf.org/doc/draft-snell-search-method/ . The resource <http://example.org/contacts> is a small table of contacts.
>> Let us imagine that
>> 
>> A. GET followed by SEARCH
>> -------------------------
>> 
>> 1. James makes a GET request on <http://example.org/contacts> via a cache C and C caches the returned  representation with etag1 ( and the same Location header )
>> 2. Ashok then makes a conditional SEARCH request on <http://example.org/contacts> via the same cache C with etag1 too
>> 
>> I think it is important that SEARCH guarantee the following:
>> 
>> it should not be necessary for the cache C to send the search request all the way back to the server example.org if it knows the query lanuage used in the SEARCH request, because it should be able to answer that
>> itself using the information from the GET in 1. above.
> 
> That not only implies that caches special-case the SEARCH method, but also know the semantics of SEARCH payloads.

yes, and I am just building a client Scala-JS store and a server Scala store to do that for a couple of query formats, under the Apache licence. 

> 
>> ...
> 
> 
> I'd prefer to concentrate on the concrete method definition first.
> 
> As Mark said, once you leave the world of GET and HEAD, standard caches won't help you anymore.

Yes, but I am not relying on standard caches. I am writing in-browser and server caches myself. The server caches are needed anyway because of the limitations of CORS.

> 
> Of course a server can indicate that a specific SEARCH response is indeed cacheable (cache-control!), but it's unlikely that generic caches will start to implement that.
> 
> If what's needed is a mechanism to discover GETtable resources that implement a specific query, something like <https://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html> might be needed.

It is important for me that the query be made directly on the resource, and that it be clear to the intermediate caches that the results are partial views on that resource, so that the intelligent cache can built these partial views together into ever more complete ones.

> 
> Best regards, Julian

Social Web Architect
http://bblfish.net/