[MERGE][bug #175886][RFC][1.0] Read superfluous bytes sent by dumb http servers by chunks.
Vincent Ladeuil
v.ladeuil+lp at free.fr
Thu Dec 13 17:42:17 GMT 2007
>>>>> "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
More information about the bazaar
mailing list