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.
Upayavira On Mon, 07 Feb 2011 19:03 +0100, "Tomaz Muraus" <[email protected]> wrote: > On Mon, Feb 7, 2011 at 4:04 PM, Jerry Chen <[email protected]> wrote: > > > > > 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: > > 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. > > > > Cool, I have updated the wiki with other ideas. > > On Mon, Feb 7, 2011 at 4:24 PM, Jed Smith <[email protected]> wrote: > > > On Mon, Feb 7, 2011 at 10:04 AM, Jerry Chen <[email protected]> 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 > > [email protected] > > >
