[UGLY HACK] Proof of concept multipart/byteranges support and connection sharing

[John A Meinel]

Michael Ellerman wrote:
> On 5/22/06, Robert Collins <robertc at robertcollins.net> wrote:
>> On Mon, 2006-05-22 at 11:15 +1000, Michael Ellerman wrote:
>> > On Sat, 2006-05-20 at 20:57 +1000, Robert Collins wrote:
>>
>>
>> > Yeah, the Curl() stuff is purely to do connection sharing. I don't know
>> > how the transport code works, but from a quick glance, if we create a
>> > new HttpClient() for each get_transport(..) isn't that equivalent to
>> > having one Curl() per PyCurlTransport() ? If so, that doesn't get us as
>> > big a win, because we create lots of transports.
>>
>> not at all - we typically use 'clone()' to 'chdir' around on a server.
>> get_transport is only called when we go from URL to Transport.
> 
> Ah ok. The catch being that HttpTransportBase(), and in fact it seems
> all the transports, implement clone() by creating a new object. So to
> share the connection meaningfully will require a bit more work, or a
> global shared connecton like sftp. But you don't like that idea, and I
> admit it irks me a little too.

All Transport objects keep track of their working directory (base). And
all paths given to them are relative to that directory.
They are meant to hide the connection, and in the case of HTTP, there
hasn't been a connection.
If you knew the server was HTTP/1.1 or supported keep-alive, you could
just open a socket and keep it open (especially helpful if using an SSL
connection).

clone() is use so that you can share whatever connection you have.
(without strictly needing a connection cache).

The connection cache has been there because of stuff like:

b = Branch.open(path)
b_parent = Branch.open(b.get_parent())

Where they might both be on the same machine. Both of the Branch.open()
functions would place a call to 'get_transport()'. Without some sort of
caching, it would have to create two new connections.

If you don't want to connect twice, *somebody* needs to know that you
are already connected.

> 
>> > Yeah, there's lots of corner cases. I think I already handle the full
>> > result case, as long as we get code 200 back, not 206. Reordering would
>> > break that code in a jiffie. Before writing a proper version I'd
>> like to
>> > check what twisted do, and/or any other implementations.
>>
>> I have only seen one complete client implementation of ranges in source,
>> and thats in squid. My advice - go with the rfc :).
> 
> Mmm, shite. I had a look at twisted, it has "TODO implement HTTP/1.1"
> which was a little discouraging. It doesn't even do ranges properly in
> the server it seems, so it's not the silver bullet I thought it might
> be. Back to the RFC ...
> 
> cheers
> 
> 

Good luck. :)

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060523/58f15e04/attachment.pgp