[Seaside-dev] Re: encoded stream

[Julian Fitzell]

On Sat, Jan 24, 2009 at 6:18 PM, Philippe Marschall
<philippe.marschall at gmail.com> wrote:
> These two are you want conversion from an external encoding
> to Smalltalk or you want to use your external encoding as your
> internal one. so your internal encoding can be either Smalltalk or
> your external one.

The problem with what you suggest is that much of the time you don't
*know* the external encoding, so saying you want to use the *same*
encoding internally as externally makes no sense.

I don't see why we can support the conversions:
a)    (probably-unknown, assume UTF-8 default)   ->   Smalltalk
b)    (probably-unknown)                                         ->
definitely-unknown

But we can't support:
c)    (probably-unknown, assume UTF-8 default)   ->   UTF-8
d)    (probably-unknown, assume UTF-8 default)   ->   UTF-16

It seems to me that (c) is what most legacy applications would want.

(b) and (c) have the same likelihood of working (ie. not erroring)
since they don't attempt to convert requests with no specified
encoding. But (c) has a higher change of producing UTF-8 because it
can convert requests that *do* specify an encoding.

While I admit that (a) is probably more useful than (d), both have the
exact same likelihood of successful conversion and if your data is
*in* UTF-16 and your tools operate on it, there's no reason you'd have
any more success going first to Smalltalk and then to your desired
encoding later (and certainly no reason you'd want (b)).

Julian