On Mon, Feb 7, 2011 at 4:57 AM, Jed Smith <[email protected]> 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. >
Even though most of the actions are by nature blocking, this doesn't mean that all of our users are using the library in a blocking way as well. Currently, if you want to launch multiple number of nodes or, for example, you are constantly polling for node status on multiple accounts, you need to wait for a previous call to return or use something like threading which is in most cases less than ideal. And yes, like you have already pointed out, this can be particularly useful when the storage part is in place. I know that the development of the Storage part has started just recently, but my thread was more about the long term plans for libcloud and not necessary about something which needs be developed as soon as possible. In the end, it would be nice to hear how most of our users are currently using libcloud and if asynchronous API would benefit them. Thanks, Tomaz > 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. >
