Comment 8 for bug 681471

Back to one of the main points of this bug, just recording the points from a discussion with mvo about:

2) for review stats the client will need to request a set of stats based on what the client wants to display in the UI (ie. user searches for 'game') (eg. /en/ubuntu/hardy/+review-stats/package_names/foo,bar,blah,url,encoded,of,course/ - if the client always requests the same number of items in alphabetical order, we may get a decent cache hit rate?)

mvo was saying that even with potentially 30k packages with reviews, it may still be better to simply return statistics for all packages at this (or some other) URL for the client to store locally. Together with strategies such as the client initially requesting the stats in a background process, subsequent requests (ie. following days) the client would just request the changes since the previous day. The responses for both of these requests could also be written to file each day on the server and served directly by apache (Note: computers that are only on every few days would need to either grab the complete file, or somehow grab subsequent updates?)

So instead of serving lots of small potentially-but-not-always-cached responses to USC clients (ie. users searching locally for 'classic games' or something), we could serve one-very-large-but-always-cached response to each client seldomly, and smaller diffs for daily changes (also heavily cached).