On Feb 6, 2011, at 10:58 PM, Jerry Chen <[email protected]> wrote: > > On Feb 6, 2011, at 9:57 PM, Jed Smith wrote: > >> At the risk of sounding dense, how does asynchronous benefit the >> library as a whole? It seems like a (potential) benefit for storage, >> but not compute. >> >> Almost every use case on the compute side is, by nature, blocking. >> Create a node, delete a node, list nodes - the calling application or >> library is going to wait on these. On the other hand, there is a >> benefit to the storage side in that the calling app can put a file >> asynchronously. Am I reading this correctly, or is there something I'm >> missing? >> >> I think in this case implementing asynchronous behavior is going to be >> important to a subset of users. Right now, storage isn't finished, so >> it poses no benefit to current use cases, does it? Are there a bunch >> of cases where a transition to a callback model would benefit the >> calling app? Would it be more effective for the calling application to >> wrap libcloud in an asynchronous framework if it so desires >> >> I'm just not seeing the benefit, that's all. > > I don't think we need async capabilities in Libcloud either. >
I was more trying to argue *against* reimplementing libcloud in node.js than *for* a port of the library. For most of the node-related stuff it's not enough to simply callback on a response anyway; in many cases you'd need to keep checking the node status until it is up, ensure consistency, etc. To actually be useful it'd require far more than a simple asyncore http client. Anyway, I'm rather out of my element having not taken in the full state of the project recently; my spidey sense started tingling with talk of brand new networking engines just for libcloud, language ports, and so on—I had to throw my hat into the "overkill" ring on that. Best, Tom > Cheers, > Jerry >
