Re: [PATCH] read-response-body should return received data when any break happens

[Ian Price <ianprice90@googlemail.com>]

Daniel Hartwig <mandyke@gmail.com> writes:

> So this is an interesting start.  The idea of buffering the transfer
> is great -- however, it falls short in this implementation because it
> is internal to read-response-body.
The buffering is useless, it's already performed by get-bytevector-n. In
this sense, it is also not internal to read-response-body

> Also, the whole business about passing the partial data out via an
> exception is very messy.
>
> What about also passing a bytevector to read-response-body?  The
> exception then only needs to mention how many bytes were read because
> the caller already has access to the bytevector aka the data.
>
> Consider this quick hack:
>
> (define* (read-response-body! r bv #:optional
>                               (start 0)
>                               (count (min (bytevector-length bv)
>                                           (response-content-length r))))
>   (and count
>        (let ((read (get-bytevector-n! (response-port r) bv start count)))
>          (if (= read count)
>              bv
>              (bad-response
>               "EOF while reading response body: ~a bytes of ~a (buffer)"
>               read count)))))
>
> which has all the features of your solution yet is much smaller and
> puts the caller in more explicit control of the buffering, which opens
> up many scenarios.
Removing the unnecessary buffering also makes it smaller. :P

> For example, reusing the same bytevector and looping over
> read-response-body! saving the results to disk each time.  This limits
> the memory use to the size of the bytevector *and* removes the copy
> operation from your implementation (bonus!).
If you wanted to do it that way, it'd be better to pass in the port
directly and cut out the middle man. 

-- 
Ian Price

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"