On Sun, May 15, 2011 at 12:19 PM, Lukas Fleischer
archli...@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).
