On 11/21/06, Daniel Rall <dlr@collab.net> wrote:
> Erik, as mentioned on IRC, here's a patch (untested) which experiments
> with injecting invocation of data transfer progress reporting callback
> into the read operations performed by ra_serf.
>
> Now, this scheme will report progress for every HTTP response we read,
> which may not be exactly what we're looking for (if logical SVN
> operations may span multiple HTTP requests).
>
> Anyhow, I think this very rough patch captures the gist of how to
> inject this sort of callback using Serf.
I think we could do it at the other end of the chain instead: put this
new bucket that tracks how much is read wrapping the socket bucket.
i.e. tweak svn_ra_serf__conn_setup to put in a progress bucket. You'd
need to stash a pointer in the connection context to that bucket to
get the values back. The only catch here is that you sacrifice some
accuracy here as you'll be tracking how much is *actually* read from
the network. You can reset the counter each time you get a new
response - and possibly report the C-L as the 'total'.
If better granularity is our main goal, the problem with doing it at
the top end - near the response bucket - (i.e. what your patch does)
is you start to play games with the type system and that scares the
daylights out of me. The response bucket is guaranteed to have
certain functions available - the trickery with the name and the usage
of the baton make it work, but icky. FWIW, though if you do stick
with this end, you should be placing the progress bucket via the
svn_ra_serf__accept_response function. That's much cleaner - i.e.
keep the bucket always there. =)
Note that even doing it at the top end means that your counts will be
off in some cases too: for example, the response will 'see' the
fully-exploded deflate buckets, but the C-L will report the gzip'd
size. I'm not sure what our API constructs are wrt progress: what
happens if we read more than we said we'd read? ;-)
HTH. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 21 16:38:21 2006