Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

[Tuomo Valkonen <tuomov iki fi>]

On 2007-10-18, Russell Shaw <rjshaw netspace net au> wrote:
> What alternative is there to UTF-8? An advantage of monoculturalism is that
> if the architecture is sufficient, everything can be consistant and easy.

There are problems with locale encoding and wchar_t, but fundamentally
their abstraction is better than specifying a Single Global Encoding.
Specifying "everything is UTF-8" is an evolutionary dead-end. I think
it's better to say "here's wchar_t and functions to operate on it. We 
don't actually specify what the actual encoding is, because then it's 
a blackbox that can easily be changed." Almost likewise with LC_CTYPE 
multibyte encodings. Unfortunately they forget to provide convenient 
functions for encoding conversions when communicating with the external 
world (that should mostly be in the libraries, seldom in applications), 
and the libc multibyte routines are a bit too limited, etc. That's 
however something that could easily be solved if people weren't so 
intent on creating another problem almost as big as the ASCII and 
Latin1 assumptions that we're still suffering from. Indeed, you do
need and want that kind of libraries to conveniently use that Single
Global Standard too; the difference is that by specifying a particular
encoding, clean design is not encouraged, and applications can and 
will expect that encoding and not do things abstractly through a 
handful of libraries that could easily be changed (or configured).

Another major problem is the unix and C "untyped" text file and stream 
legacy, so you have to assume every file is in some encoding -- ASCII, 
LC_CTYPE, UTF-8, or so, which it may not be. That could also be solved 
by e.g. creating a "typed" plain text file (could be mime type stored
on fs) and stream format, assuming the locale encoding for legacy
stuff, and opening text files though some library as text streams, 
that then does the conversions to the abstract application internal
encoding (either multibyte encoding -- not necessary LC_CTYPE, to 
allow wider character ranges internally in programs than in legacy 
files --  or wide character). That's a rather big task, but not really
that much bigger than a transition to a global monoculture.

-- 
Tuomo