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).