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