incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Schwartz, Philip Marc (LNG-BCT)" <>
Subject RE: [libcloud] libcloud roadmap and plans for the future
Date Tue, 08 Feb 2011 13:57:50 GMT
I would also vote -1 to twisted. But 0 to async. I am for async to a point as long as it is
setup as a per instance option for the user.

In other words making a secondary async http client library to allow usage if desired with
no lasting effect on the core of libcloud. The moment we make a change as drastic as making
the http client async will be the moment that we make people using the library a little angry
as most would not want an async http client for compute work.

Thank You,
Philip Schwartz
Software Engineering
LexisNexis RS
O - 561 999 4472
C - 954 290 4024

-----Original Message-----
From: Upayavira []
Sent: Monday, February 07, 2011 3:43 PM
Subject: Re: [libcloud] libcloud roadmap and plans for the future

Personally, I'd be concerned if Libcloud took on Twisted. I (as
something of an outsider) see Libcloud as a lightweight library for
interfacing with cloud providers. If you add Twisted, you add a
heavyweight dependency to a lightweight library, and suddenly deploying
your Libcloud based apps becomes a whole lot harder, especially if
you've never used Twisted.


On Mon, 07 Feb 2011 19:03 +0100, "Tomaz Muraus" <>
> On Mon, Feb 7, 2011 at 4:04 PM, Jerry Chen <> wrote:
> >
> > On Feb 7, 2011, at 8:48 AM, Tomaz Muraus wrote:
> >
> > > On Mon, Feb 7, 2011 at 4:57 AM, Jed Smith <> wrote:
> > I agree. Speak up, people!
> >
> > BTW, I started up a wish list on the wiki a while back:
> >
> >
> > 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.
> >
> Cool, I have updated the wiki with other ideas.
> On Mon, Feb 7, 2011 at 4:24 PM, Jed Smith <> wrote:
> > On Mon, Feb 7, 2011 at 10:04 AM, Jerry Chen <> wrote:
> > >
> > > 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.
> >
> > I believe it would. You now need to track what requests you have out
> > and call the appropriate callback, a very difficult (and tedious
> > task). A supposedly stateless library just inherited a /lot/ of state.
> >
> In Twisted and other event-driven system everything runs inside a single
> thread (reactor) and as long you are only using asynchronous API, you
> don't
> need to worry about race conditions.
> In any case, adapting the library for async stuff would definitely
> require
> some refactoring, but I could argue that this might not be such a bad
> idea.
> Anecdote: I solved this problem for the Linode iPhone app. If you're
> > not familiar with UIKit/Foundation development for iOS, it's all
> > asynchronous. I spent very many hours debugging the code that did the
> > linkage between APIRequest instances and the callback event on them.
> > It got so difficult to do properly with Apple's APIs that I eventually
> > stumbled upon a hopelessly inelegant solution: every request the
> > iPhone app makes is a batch, with a test.echo action containing an ID
> > which is a key into the pending-requests dictionary. Seriously.
> >
> > That's what asynchronous ends up becoming in a request-receive
> > environment. It's a rabbit hole of inelegant solutions and a lot of
> > tedious state tracking in the library.
> Yes, I agree, debugging in a lot of callback oriented frameworks can be a
> huge pain. One of the good examples of this is NodeJS - with a lot of
> nested
> callbacks and no long stack traces finding a root cause can be pretty
> painful (Twisted partially solves this with defer.SetDebugging(True)).
> So, yes, in general debugging and writing asynchronous code can be
> painful,
> but Twited has enough of syntactic sugar which makes it a lot less
> painful
> (deferreds, inlineCallbacks, ...).
> > --
> > Jed Smith
> >
> >

This message (including any attachments) contains confidential information intended for a
specific individual and purpose, and is protected by law.  If you are not the intended recipient,
you should delete this message.  Any disclosure, copying, or distribution of this message,
or the taking of any action based on it, is strictly prohibited.

View raw message