> > We could try, I guess, if the website can handle the traffic (we may be > talking about 100s of GB per month just for the catalog). >
I know I'm jumping in late here, but a few thoughts... 1. HTTP has pretty robust caching mechanisms - is the update center making use of them? A 304-Not-Modified response is 200 bytes or so; and most requests will receive the same catalog they got last time. I'm guessing probably not, just by the time the update dialog takes before controls are enabled. But it would be a pretty trivial change to add that. 2. I thought there was some talk about using Maven repos for the actual bits. If we're publishing Maven artifacts, all requests for actual NBMs could be redirects to Maven central or similar, making the catalog the only request that needs to be managed. 3. CDNs - particularly Cloudfront - are remarkably cheap - https://aws.amazon.com/cloudfront/pricing/ US $0.85 / Gb. I don't know if there's any budget for that sort of thing in Apache-land, but if the catalog were on a CDN, that would take care of that. 4. Failing that, I have a little corner of the web, and I bet a few others here do too, and I could imagine donating some bandwidth to host a mirror. A long time ago I wrote a little update center server for my own purposes - https://github.com/timboudreau/meta-update-center - or running here https://timboudreau.com/modules - which is a tiny server that runs in a <16Mb footprint, can handle 10k concurrent connections and just proxies NBMs hosted elsewhere. That's designed specifically to always serve the latest version of things, but it would be easy enough to adapt a few things to have it mirror a catalog and keep its copy up-to-date. Then you just need a strategy to round-robin among them and fail over if one is down - I could imagine using DNS SRV records for that. Anyway, I read the summary, and it sounds like there's a plan, but it also sounds like the Apache mirrors are a bit sub-optimal, so I thought I'd throw that out there. -Tim -- http://timboudreau.com
