[Seaside-dev] Re: encoded stream

[Philippe Marschall]

2009/2/5 Lukas Renggli <renggli at gmail.com>:
>> I think Lukas actually ran into problems with this... Lukas?
>
> Yes, I am totally frustrated. I have an image full of dirty packages
> and everything is broken. ;-)
>
> The problem is that WACodec is not suitable for streaming:
>
> - WACodec works with Strings instead of Streams. So whenever you
> convert something a copy is created.
>
> - WACodec instances are singletons. They use a critical section to do
> the conversion. I wonder why nobody has ever complained? Today when a
> request/response is converted all other request handling is basically
> suspended.
>
> I suggest the following refactoring, but I need help because it
> affects a lot of code:
>
> - Change WACodec to a factory object for stream encoder/decoder.
>
> - The WACodec class to be used is specific in the WAServerAdaptor.

Then the configuration of the encoding should be removed from the application.

> - WANullCodec is the default codec to be used and the only one shipped
> with Seaside-Core. It does nothing and provides the legacy WAKom
> behavior.
>
> - WACodec understands the methods #encoderFor:, #decoderFor:,
> #urlEncoderFor:, #urlDecoderFor:, ... and wraps streams with platform
> specific encoding strategies. Most platforms (with the exception of
> Pharo) have highly efficient stream wrapper in their core library that
> can be answered here.
>
> - Platforms provide a limited set of useful subclasses of WACodec,
> like WAUtf8NativeCodec, WAUtf8Utf8Codec, WAIsoUtf8Codec, etc. One
> could also think of codexes that configure themselves using one of the
> detection strategies in other web frameworks.
>
> This kind of refactoring avoids unnecessary copying around and works
> well with buffered and streamed request processing. The streamed
> server currently includes an ugly hack and a lot of platform dependent
> duplicated code to enable encoding.
>
> What do you think?

Fine with me.

Cheers
Philippe