incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomaz Muraus <>
Subject Re: [libcloud] libcloud roadmap and plans for the future
Date Mon, 07 Feb 2011 14:48:12 GMT
On Mon, Feb 7, 2011 at 4:57 AM, 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.

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.


> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message