On Wed, Jun 2, 2010 at 11:39 PM, Kimbro Staken <[email protected]> wrote:
> [...] expecting the person that maintains pricing to have any > kind of access to DNS is just not going to be the case [...] DNS record would be updated from a single location, every time new code is pushed to the main repo. So the workflow remains the same: committers push code with new pricing information. > 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? Paul's message led me to believe that the ASF needed alternatives to simply hosting a static file on a public HTTP server. If that's not the case, obviously there's no need for anything fancy. If, on the other hand, the kind of traffic generated by a great number of libcloud clients continuously polling for new pricing information is actually a problem for ASF's infrastructure, even with http caching (think many tcp connections), then DNS might be a viable alternative. I am not familiar with the ASF infrastructure, so I can't answer that. I think we are among grown-up engineers and all understand that the simpler the tool, the better. Best, Solomon > On Wed, Jun 2, 2010 at 9:58 PM, Alex Polvi <[email protected]> wrote: >> On Thu, Jun 3, 2010 at 4:39 AM, Jerry Chen <[email protected]> wrote: >>> >>> On Jun 2, 2010, at 11:34 PM, Solomon Hykes wrote: >>> >>>> On Wed, Jun 2, 2010 at 9:24 PM, Dan Di Spaltro <[email protected]> wrote: >>>>> I don't know enough about the DNS protocol, but are there limitations. >>>>> This >>>>> seems like a weird way to do it... Are we just doing it to be novel, or I >>>>> don't see why a typical webserver serving JSON (pretty well tested) set up >>>>> isn't good enough. >>>> >>>> The 2 things you get for free with DNS are 1. caching and 2. virtually >>>> unlimited scalability. >>>> >>>> I would evaluate how much work and money would be spent on >>>> implementing a cache system in libcloud and hosting a json file >>>> reliably. Depending on the answer, using DNS will make sense or not. >>>> Definitely no point in doing it for the sake of novelty. >>> >>> To add to that, this is how I understand this approach in general: >>> >>> * Pros for DNS >>> ** Stable >>> ** Existing infrastructure >>> ** Replication/caching is "free" >>> ** Trust/validity (ownership of domain) >>> ** Lends to discovery >>> >>> * Cons for DNS >>> ** Propagation delay/limitation >>> ** Records have a finite length limitation, e.g. SPF needs indirection >>> ** Different protocol than Provider APIs (DNS v. HTTP) >>> ** Discovery not usually needed, as a lot of other things are already >>> hard-coded, viz. URL endpoints >>> ** Non-core library or additional module needed for DNS TXT queries >> >> To be fair.... >> >> * Pros for JSON >> ** Supported by any language (normally w/out additional dependencies) >> ** Behaves like the cloud providers themselves do >> ** Caters to web developers, the likely candidate for people actually >> building on this stuff >> ** Human readable with nothing more than curl/browser >> ** KISS >> >> * Cons for JSON >> ** We have to run a static webserver (wait, that's not hard at all and >> can just use S3) >> ** Caching (again, it's a static file, so this is not a problem) >> >> I'm not convinced at all that we should complicate things with DNS. >> >> -Alex >> >> -- >> co-founder, cloudkick.com >> twitter.com/cloudkick >> echo V2UgYXJlIGhpcmluZyEK | openssl base64 -d >> >
