On 24 July 2012 17:39, Sean Cribbs <[email protected]> wrote: > > So, ideally this would just be an alternate transport. However, I suspect it > might require adding optional kwargs to every call, where you might be able > to pass a callback (sorry, I'm not that familiar with Twisted, but it's that > way in Ruby's Eventmachine). If this is the case, I'd be concerned about > adding the additional complexity.
Twisted is built around "Deferred" objects[1], which encapsulate the callbacks. Rather than passing callbacks into the function, the function returns a Deferred which you add the callbacks to. When the async operation completes, the result is passed to the first callback in the Deferred's callback chain. That callback's result is passed to the next callback, and so on. There's a rather more comprehensive explanation in the footnoted link. >> I think it would be possible to restructure the Python client somewhat >> to decouple the higher-level operations from the lower-level network >> operations in a way that would let us switch between Twisted-style >> async I/O and more traditional blocking I/O. This would probably be a >> fairly invasive change in some ways, but shouldn't have any noticeable >> impact on the external API. I'm hoping it'll make the >> ConnectionManager replacement cleaner and more flexible, but I don't >> have a good enough mental model of the system to be sure. >> >> As the person proposing this, I'm happy to put some effort into >> hacking up a prototype to see if this is actually a workable idea and >> to do the bulk of the implementation work if it is -- it'll save on a >> bunch of Riakasaurus maintenance in the future if we can pull it off. >> I'm proposing some pretty drastic surgery to the existing codebase, so >> I'd like to know if other people (especially Sean) think it's a good >> idea before I sink too much time into it. > > Please do send me or the mailing-list an outline of this, I'm interested in > hearing how it would work. I don't have a solid idea of how it's all going to fit together yet, but it'll almost certainly involve breaking up all functions/methods that do any network I/O and then reassembling in different ways based on which backend is being used. We've done something similar to build a kind-of-ORM-thing on top of both the Python client and Riakasaurus, but that uses a completely different mechanism which isn't really suitable here. I'll post an update as soon as I have something a little more concrete. [1] http://twistedmatrix.com/documents/current/core/howto/defer.html Thanks, --J _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
