On 5/11/2010 10:10 AM, Igor Stasenko wrote:
> On 11 May 2010 19:21, Andreas Raab<andreas.raab at gmx.de>  wrote:
>> And that works out of the box, too :-) With a small modification. The
>> convenience APIs on the class side close the client and prefetch the
>> response. In other words, in order to stream you need to write, e.g,
>>
>>   client := WebClient new.
>>   [resp := client httpGet:'http://www.squeak.org'.
>>   length := resp contentLength.
>>   stream := resp contentStream.
>>   [length>  0] whileTrue:[
>>     stream next: (length min: 100).
>>   ]] ensure:[stream close].
>>
> good. Its quite similar to what i did in SCouchDB.
>
> But i'd like to note, that content length is not mandatory field, and
> your example won't work for a content with undetermined length.

Of course. It's an example after all. That's why I said that if you need 
fully featured stream support you should be using the high-level 
functions provided by WebClient which deal with these issues.

Cheers,
   - Andreas

>> A couple of things to keep in mind though: The above doesn't deal with the
>> server returning an HTTP/1.0 response (no content-length) or other
>> specialties like chunked-encoding content transfer. That's why the
>> high-level functions are advantageous because they deal with all of that.
>>
>
> In SCouchDB I dealing with chunked-encoding content by wrapping the
> original stream with chunked stream
> which deals with this transparently, and so the end user don't have to
> deal with it by itself.
> Then, similarily, for utf-8 content, i also just wrapping a source
> stream with own utf8-decoder stream,
> and so, the content consumer don't have to care about it by itself,
> all it needs to know to use stream protocol.
>
> So, stream-wrappers is a powerful abstraction, alas, the current
> Stream package lack of good support for 'wrapper stream' such kind of
> abstraction. :(
>
>> Cheers,
>>   - Andreas
>>
>>
>