PYCURL considered unprogressive
Martin Pool
mbp at sourcefrog.net
Thu Apr 13 03:56:22 BST 2006
On 13/04/2006, at 6:46 AM, Robey Pointer wrote:
> On 10 Apr 2006, at 5:56, Aaron Bentley wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Sorry, I just had to :-)
>>
>> One of my longtime niggles is that the inventory file download
>> takes a
>> long time, and during that time, no progress is indicated. I thought
>> this ought to be easily fixed; our transport interface returns a file
>> object, and files can be read in pieces of fixed size. So we
>> ought to
>> be able to read a bit, update a progress bar, read a bit more, etc.
>>
>> This is the approach I started on here:
>> http://code.aaronbentley.com/bzr/bzrrepo/bzr.progress/
>>
>> The Transport API implies that f = t.get() will be constant-time, and
>> f.read(x) will take time proportional to the size of x. The urllib
>> transport does behave this way. But this isn't guaranteed, and in
>> fact,
>> it's not what the PYCURL transport does.
>>
>> There appears to be no way to convince PYCURL to transfer data
>> iteratively: You simply call perform, and you are notified when the
>> transfer is complete. The only way to do things in chunks is to
>> provide
>> a consumer as WRITEFUNCTION, and we can't implement a file-like
>> object
>> as a consumer.
>>
>> PYCURL does support a PROGRESSFUNCTION callback, so I think we'll be
>> able to get progress updates out of it. The problem is that we
>> shouldn't do progress updates in two places. So how do we know
>> whether
>> to do them on read()? We can detect StringIO, I guess. It hardly
>> seems
>> like a good approach.
It has to be said that this is something that Twisted would probably
accommodate well.
--
Martin
More information about the bazaar
mailing list