[RFC] Multipart support for _urllib_

[Michael Ellerman]

On 6/21/06, Martin Pool <mbp at canonical.com> wrote:
> On 20 Jun 2006, John Arbash Meinel <john at arbash-meinel.com> wrote:
>
> > > That is indeed impressive.  I wonder if we can get down towards that
> > > number by just progressively replacing things in urllib and not
> > > depending on pycurl?
> >
> > I think pycurl gives us connection sharing/keep alive. Which becomes
> > even more important over SSL.
> > I'm a little curious if performance would be better if we shared the
> > range-request object with the full-request object, but I have the
> > feeling we tend to use either readv() or get(). We probably don't mix
> > them around much.
>
> Yes, connection sharing is important.  However, it should be possible to
> do that within Python too, by just keeping a reference to the open
> socket.  After the previous conversation about connection caching, we'd
> probably want to share these among related transports (transports
> created by cloning from each other.)

Agreed, it's just more work.

> > Well, that shouldn't be too bad. How much testing do you want in place
> > before it is considered worthy of merging? (I would like to get some
> > testing as well, but I have some other major focuses this week, and
> > would like to see it merged soonish).
>
> Well, what I would *really* like is to encourage bzr developers to get
> to into the habit of test-driven development; writing things as you go
> along.  One thing I've learnt is that if you leave tests until later it
> just gets harder to add them.

Oh but I did use TDD, the test was "can I branch bzr.dev" ;)

Point taken, and I actually did look into writing tests first, but I
really don't grok the testing infrastructure very well, and then
people started getting impatient so I just got it working. I don't
expect you to merge it without tests.

cheers