[MERGE][bug #175886][RFC][1.0] Read superfluous bytes sent by dumb http servers by chunks.

[Vincent Ladeuil]

>>>>> "john" == John Arbash Meinel <john at arbash-meinel.com> writes:

<snip/>

    john> Well, emitting it only once is just having some state
    john> on the HTTPTransport. But I suppose you would end up
    john> wanting to share that state between clones, etc.

Yes, otherwise I end up emitting it quite a lot.

    john> I'm not sure about issuing it only above a byte
    john> threshold. I guess that is reasonable, since then you
    john> only warn if it seems to be a performance issue.

That's the idea.

    john> I suppose doing it there means you cover both pycurl
    john> and urllib.

No :-/ But the bug is about urllib...

    john> However, will it warn in the case that I ask for the
    john> last 10 bytes of a pack file, and I get back all 10MB?

Neither...

    >> 
    >> I'd prefer to wait for a bit more feedback from real cases to
    >> decide if this complexity is worth it
    >> 
    bialix> 2) Your warning message should be marked with some
    bialix> distinct prefix, IMO.  I suggest to use something
    bialix> like: "bzr: WARNING: Got a 200 response..."
    >> 
    >> Why make a particular case ? Plus, prefixing by 'bzr:' seems a
    >> bit strange, we *are* bzr ;)
    >> 
    >> Vincent
    >> 
    >> 

    john> Well, we do:

    john> bzr command
    john> ^C
    john> bzr: interrupted

    john> I think it is fairly common for programs which write
    john> out information messages to inform the user who is
    john> giving those messages. I think the "bzr: interrupted"
    john> is mostly because it is returning control to the shell,
    john> so that last line could be confusing.

    john> Personally, I'm fine with just WARNING:.

Ok. After all, I just used bzrlib.trace.warning like the rest of
bzrlib...

        Vincent