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

[Nala Ginrut <nalaginrut@gmail.com>]

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

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 <nalaginrut@gmail.com> 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 <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: 2962 bytes --]