twisted much?

[David Allouche]

On Wed, 2005-06-08 at 13:32 +1000, Martin Pool wrote:
> (Maybe some of the Canonical people have an opinion on this.)
> 
> To get really good HTTP download performance it seems that we need to
> do parallel/overlapped downloads.
> 
> One way to do that would be to use Twisted Python's http client
> library.  Some people like it very much and some strongly dislike it.
> It would introduce a sizeable dependency.

When the parallel downloads issue came up, I initially wished Twisted
would be used. Even though I had some painful experiences with it, and
there is plenty of crack in it, the basic reactor design is pretty sound
and that's the best framework around for asynchronous APIs.

After talking with Aaron Bentley, and thinking about a pipelining issue
on some code I'm working on, I realised that using threads would
probably be a reasonable compromise. The downloader threads can be well
isolated from the rest of the code using synchronised queues, and that
would make it possible to keep the rest of the API simple and
synchronous.

I talked with Robert Collins about my ideas on implementing simple
pipelining with threads. And then he convinced me that using Twisted
would be a indeed good thing.

     1. The Twisted reactor can be started and stopped at will. You only
        need to run the reactor while you need asynchronism. That makes
        it possible to encapsulate asynchronous code and provide a
        synchronous API. 
     2. Providing a fully asynchronous bzr API (doing voluntary
        scheduling when not network-bound) would very much simplify the
        implementation of a good GUI, that must stay responsive under
        heavy load, and a smart server, that is a network-centric
        application.

There might not be an immediate compelling need for making bzr fully
asynchronous, but a stated goal (implementing a GUI) and much desirable
feature (smart server) would greatly benefit from it.

As usual, that's just my two cents, and those who actually write the
code get to make the decision.

-- 
                                                            -- ddaa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050613/3f5d2469/attachment.pgp