[aur-dev] [PATCH 1/1] add support for etag and conditional get (if-none-match)

[elij]

On Sun, May 15, 2011 at 12:19 PM, Lukas Fleischer
<archlinux at cryptocrack.de> wrote:
> On Fri, May 13, 2011 at 12:55:40PM -0700, elij wrote:
>> Add etag and if-none-match conditional get support. This will allow
>> 'smart client' to save network bandwidth, as they can save the etag
>> hash value for queries and test it later. Still an http request because
>> this patch specifically sets a cache lifetime of zero, and must-revalidate.
>> The benefit here is bandwidth savings. Caching based on expires headers would
>> likely be counter productive, as the api data can change rather quickly...but
>> etag is a nice compromise, and could be quite beneficial for bandwidth recution
>> in some scenarios.
>> ---
>>  web/lib/aurjson.class.php |   30 +++++++++++++++++++++++++++++-
>>  1 files changed, 29 insertions(+), 1 deletions(-)
>>
>
> I kinda like that one although I'm not really sure if this kind of
> caching is convenient enough here... Having a bit more detailed look at
> the single query methods:
>
> * search, msearch: Probably won't be repeated on a single client very
>  often ("repeated" meaning doing the same search query more than once).
>
> * info: Gain will probably be low as the query results are very small.
>
> * multiinfo: Query results will change quite often, while the actual
>  diffs will be small in most cases.
>
> Some delta based stuff may be more effective here but that will probably
> be overkill. ETags seem to be a good compromise, yeah :)

Yeah. I see a couple of instances that would benefit from it.
1) Direct browser viewing of api urls. Developers or end users
entering query strings manually.

2) My live-search implementation (and similar type apps) _should_ work
better, as back and forward button (or identical search terms) should
be cached client side by the browser.

3) A cli client could be modified to cache data, but I imagine the
benefits here would be small, as I don't believe end users would
repeat many queries in a short enough timeframe (before some data
changes) to get much benefit from caching. Who knows though. heh

4) Could be a benefit for large groups of clients behind a cache proxy.

5) Could be a benefit if the arch server admins ever decided to throw
varnish in front of the aur (or just the api).