On Tue, 16 Mar 2010, Igor Stasenko wrote:

> On 16 March 2010 04:46, Andreas Raab <andreas.raab at gmx.de> wrote:
>> On 3/15/2010 7:44 PM, Igor Stasenko wrote:
>>>
>>> Since SocketStream caching the data it reads, then instead of
>>> resetting the buffers it should convert them and avoid losing the
>>> data.
>>>
>>> What you think is an appropriate solution to this?
>>
>> Don't "reset" the buffers; simply convert them to the proper ascii/binary
>> format.
>>

This is what we are doing in StandardFileStream.

>
> There could be an alternative approach:
> - keep buffers in a single (binary) format and covert an output
> depending on mode.

This is exactly what we were doing in our own SocketStream-like class. For 
a general purpose SocketStream this might give some extra complexity for 
the implementation, but it'd also allows us to use the stream primitives.

There's a third option if you want to optimize for rapid ascii/binary 
mode changes: store both the binary and the ascii buffers and fill/copy 
them in a lazy way.


Levente

>
> The choice is, when you should pay the conversion price:
> - each time you read something
> - each time you switching the mode
>
> If input is a mix of ascii/binary content, it will be very ineffective
> converting the cache each time mode switching.
> For example - HTTP 'transfer-encoding: chunked'.
> Content may be a binary data, but it could be chunked, then input
> becomes a mix of
> binary data and hexadecimal ascii values, and crlf's.
>
> So, it requires mode deep analyzis than just saying 'convert it' :)
>
>> Cheers,
>>  - Andreas
>
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>
>