[Seaside-dev] encoding/decoding Streams

[Paolo Bonzini]

>> 1) Would it make sense to change WACodec>>#encode: and WACodec>>#decode: to
>> > accept streams instead of Strings?
> 
> The servers I had to do with deal with Strings and not Streams. 

Swazoo supports feeding data to the socket directly for a stream, but 
the Seaside adaptor cannot use the feature because it has to convert the 
WAResponse's contents to a String just to feed it to the codec:

     contentsOfResponse: aResponse
         | contents |
         contents := aResponse contents contents.
         ^aResponse contentType isBinary
             ifTrue: [contents]
             ifFalse: [self encode: contents]

If it wasn't for this, it would be enough to have something like

     nextPutContentsOfResponse: aResponse onto: aStream
         | contents |
         contents := aResponse contents.
         ^aResponse contentType isBinary
             ifTrue: [
                 "Did you know #nextPutAll: accepts a Stream? :-)"
                 aStream nextPutAll: contents]
             ifFalse: [self encodeStream: contents onto: aStream]

and basically using it in #convertResponse: by changing

     swazooResponse entity: (self contentsOfResponse: aSeasideResponse).

into

     self nextPutContentsOfResponse: aSeasideResponse onto: swazooResponse.

(It's a little more complicated because you'd need the SwazooRequest to 
make the SwazooResponse, using "swazooRequest streamedResponse", but not 
a big deal).

Also, I don't know about Squeak but in both VW and GNU Smalltalk 
reencoding is Stream-based, and it to reencode a String you just have to 
wrap it again in a Stream.

     encode: aString
         ^(I18N.EncodedStream on: aString readStream from: 'ISO-8859-1'
             to: encoding) contents asString

>> 2) The tests for codecs assume that the source encoding is ISO-8859-1.
> 
> I don't see what you mean here.

The .mcz files downloaded from SqueakSource pass an ISO-8859-1 string to 
#encode:, and check that the result is in whatever encoding was passed 
to #newForEncoding:.

>>  This
>> is fine for testing purposes, but not necessarily for deployment. Would it
>> make sense then to change the constructor so that it can take a source and
>> destination encoding?  Or is there something I'm missing?
> 
> I assume the current tests cause a problem somewhere. Can you elaborate?

No, the tests are not a problem.  But in order to pass them, I had to 
hardcode ISO-8859-1 as the source encoding in GNU Smalltalk's default 
codec (see again how #encode: is implemented, above).

A deployment that wanted to use another source encoding (for example the 
legacy encodings for Far East, or another ISO-8859 encoding for Greece, 
Eastern Europe or Arabic countries) would have to create another WACodec 
subclass.

Paolo