On Wed, 2010-06-02 at 23:39 -0700, Kimbro Staken wrote: > Wasn't the goal here to have a very easy way to update prices? How > many people actually have access to update DNS records at their > company? How about for this project? I guarantee that if you pursue > that path you'll get data that's even more stale than having it > hardcoded in the source. Also if you want providers to help keep that > data current, expecting the person that maintains pricing to have any > kind of access to DNS is just not going to be the case and getting a > DNS change through the internal process of any modestly sized company > can be non-trivial and can take a lot of time. Also if you can't get > the ASF to deliver a static file from an HTTP server, what makes you > think that getting them to add stuff to DNS will be easy?
Interesting perspective. Some thoughts/questions: Who is going to be responsible for maintaining this? Is this going to be done on the Apache side or on the provider side? If it is done on the Apache side, which group of people will need access in order to do it? Certainly Paul could edit DNS TXT records, but would it be possible/feasible to grant write access to other libcloud committers to just that small portion of the DNS setup without giving over control to, e.g. libcloud.apache.org? If we were to go to http, how would we prevent libcloud from downloading this data on every method invocation? This has been an issue in the past at the ASF, where code pulls from Apache servers every time it is invoked (in that case it was pulling a DTD every time it parsed some XML that referenced the DTD!!). Libcloud doesn't have any caching mechanisms or data storage mechanisms that I am aware of at present, and I'd imagine that in many circumstances libcloud doesn't stay resident in memory for long enough for simply store it in memory to give sufficient caching. It'll probably turn out that the best place to keep it all is in Subversion :-P Upayavira
