Subject: Re: bin/12017: how to enable multibyte locale (and problem around it)
To: None <itojun@iijlab.net, soda@sra.co.jp>
From: Noriyuki Soda <soda@sra.co.jp>
List: netbsd-bugs
Date: 01/23/2001 18:04:04
> >More importantly, we should have the way to extend locale dynamically
> >(like Solaris and other OSes).
> >That is the problem which I'm worrying.
> 
> 	how frequently will it happen to us?  given the (guessed) frequency
> 	of such event, i think we maybe able to ask people to grab a new libc
> 	(even with the same minor).  

For encoding module, at least we should have one major change to
support localedef.
For LC_TIME module, every language/country potentially requires 
dedicated module. (e.g. think about getdate(3) on Solaris)

>	static binaries cannot benefit from the
> 	new engine though.

Yes, for now.
But theoretically static binary can load module dynamically,
although it is hard with current implemenation.

> 	when encoding engine API changes, we need to ask people to
> 	upgrade anyways.

No.
We should make locale module compatible always.
If it becomes incompatible, third-party supplied locale module becomes
broken.
We should embed module interface version number to locale module
to make it always compatible.
 
> >> 	also, since charmap is a static table (not conversion formula)
> >> 	there's no reason for it to require different encoding modules
> >> 	per different charmaps.
> >Charmaps file cannot cope with stateful encoding.
> >So, if there is other stateful encoding, dynamically loadable encoding
> >module is needed.
> 
> 	i can't agree more with the above.  but what's the point?
> 	charmaps are inherently for stateless encodings.

The point is that we should make encoding module dynamically loadable.
Because even when we have charmaps file, we cannot cope with newly
defined stateful encodings.

> >(LC_TIME and LC_COLLATE needs dynamically loadable modules, too.)
> 
> 	could you give me an example why glibc does not need it,

Because glibc always sucks? :-)
Seriously, it seems that glibc developers don't know existing i18n
frameworks. Probably this is the reason why they don't have it.

> 	and why we do need it?

Think about traditional style of kanji number representation?
(Not "2 0 0 1", but "2 1000 1" in kanji).
--
soda