[Seaside-dev] Re: encoded stream

[Philippe Marschall]

2009/1/26, Julian Fitzell <jfitzell at gmail.com>:
> On Sun, Jan 25, 2009 at 4:46 PM, Philippe Marschall
> <philippe.marschall at gmail.com> wrote:
>> That doesn't make sense. If you use utf-16 internally and I can't
>> imagine anybody wanting that then you'd almost certainly want to use
>> it for external as well.
>> ...
>> But request don't in general. Seriously if a strange request comes in
>> you probably won't even notice. And if you do you won't find out what
>> the encoding really is. You just can't in practice because the
>> information isn't there.
>
> Which is exactly my point and therefore I think you must be missing
> it. ;) You're picking on UTF-16 as a straw man argument. It's totally
> irrelevant what internal encoding the user wants to use and my
> argument is exactly the same no matter which one you pick (including
> using UTF-16 internally and externally).
>
> My _only_ point is the following:
>
> *** We are throwing away information when we *do* know the encoding
> (b) coming in because we are not allowing the user any way to specify
> what internal encoding they want to be using (c) except, for some
> reason, if it is "Smalltalk". ***
>
> The user can only pick "hopefully Smalltalk" or "unknown" for their
> internal encoding. I think they should be able to pick "hopefully
> UTF-8": it would be at least as useful as "unknown" and (I think)
> easier to understand.

I think there are several different issues:
1. Should we make the configuration and their consequences for explicit?
2. What should the configuration options look like?
3. Should we provide some kind of accessor to what we think the
internal encoding is?
4. Should try to detect if incoming data is in the expected encoding?
5. Should we support some non-Smalltalk encoding internally that is
different from the external encoding?
6. Where should be encoding be specified?

1. Yes, "encoded server adapter" is not the best name ever.
2. Dunno, see above.
3. Sure, why not, for example:
context usesSmalltalkEncoding
   ifTrue: [ 'Smalltalk' ]
   ifFalse: [ server encoding ]
4. No, the browser does not send in what encoding the data is. I know
because all but the very latest version of Kom ("Dolphin & Monkey") do
blow up if the browser sends the encoding. Additionally we have no way
of finding out in what encoding incoming data is by just looking at
it.
5. No, until we actually have somebody who needs this I consider this
a purely theoretical use case.
6. Lukas made a pretty good argument for doing it in the server adapter.

Cheers
Philippe