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

[Nala Ginrut <nalaginrut@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]

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 <mandyke@gmail.com> wrote:

> On 16 March 2012 02:37, Ian Price <ianprice90@googlemail.com> wrote:
> > Daniel Hartwig <mandyke@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 2323 bytes --]