> I've checked them, but I don't want to integrate them as is, because
> that would break compatibility both with older versions of Squeak and
> with VisualWorks.
>
> Generally, I feel like Seaside should try to be pretty ignorant about
> encoding issues - it should just be expecting to get a MultiString in
> and push a MultiString out, I guess. The messy business of going back
> and forth to raw bytes should be the job of the underlying platform
> and webserver - or, if (as with Comanche) the webserver doesn't handle
> it properly, it should be done by the webserver's adaptor.
>
> Given all this, I think the best approach would be to create a new
> subclass of WAKom that does the conversions (rather than doing it in
> the base WAKom, and rather than modifying WARequest). Then people
> running on Squeak 3.8 that wanted to use and see UTF8 data as
> MultiStrings could just choose to start up (eg) WAEncodedKom instead
> of WAKom, and nobody else would be affected.
>
> Sound reasonable?
Yes, it will be definitely the best solution. Now I will look at encoding
problems in Seaside 2.6.
-- Pavel
|
