After a long long discussion with ijp, I realized that this could be an easy patch because get-bytevector-n handles most of the work. So I'll raise another thread about this topic for a new version patch. Thanks for discussion! On Fri, Mar 16, 2012 at 10:23 AM, Nala Ginrut wrote: > Thanks for reply! > @ijp: Yes, I think return received data within exception is ugly. But I > have to do it because my consideration is to return received data when > *any* exception happens. So if it's not a common connection error, I have > to catch it to return the received data, then re-throw the same > exception(and cut the received data). Because other program may expect this > exception. But I don't claim that this is the best design. Anyway, just a > proposal. > @Daniel: I realized that seems make "get-bytevector-n" return the received > data rather than read-response-body is better. But I'm afraid that it'll > conflict with the definition "get-bytevector-n". Say, we ask for n bytes, > but it returned m bytes less than n. So the user maybe get confused with > the name "get-bytevector-n". > > > On Fri, Mar 16, 2012 at 2:48 AM, Daniel Hartwig wrote: > >> On 16 March 2012 02:37, Ian Price wrote: >> > Daniel Hartwig writes: >> >> 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. >> > >> >> Indeed. The procedure shown is similar to one from one of my own >> projects which features the write-to-disk internally. >> >> I guess it pays to keep in mind that it is trivial to rearrange >> procedures such as this to suit any particular situation. The OP >> appeared--to me--to be very over worked for the task. >> >> Perhaps such error-tolerance/streaming capabilities can be tied in at >> a level closer to get-bytevector-n... >> >> >> Regards >> > >