On Feb 7, 2011, at 8:48 AM, Tomaz Muraus wrote: > 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.
As long as the abstraction doesn't create weird race conditions, nor forces us to modify each driver for async stuff to work, I would be okay with this capability. I just can't wrap my head around how one would test for correctness and stability. > 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. I agree. Speak up, people! BTW, I started up a wish list on the wiki a while back: http://wiki.apache.org/incubator/LibcloudWishlist I'm not convinced it has the best voting mechanism (it acts like a IRC topic vote!) but at least we can get an idea of the weighting. Cheers, Jerry
