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