[Seaside-dev] Re: encoded stream

Julian Fitzell jfitzell at gmail.com
Fri Feb 6 11:51:38 UTC 2009


Sounds fine to me from your description...

On Thu, Feb 5, 2009 at 3:12 PM, Lukas Renggli <renggli at gmail.com> wrote:

> > 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.
>
> - 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?
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20090206/a55c1df6/attachment-0001.htm


More information about the seaside-dev mailing list