>> 	even if we use charmap, encoding module won't be that big i guess.
>> 	data (the conversion table generated from charmap) will be big though.
>But the charmaps file is certainly one of examples that current 
>implementation is not complete, isn't it?
>(Also, there should be a way to extend LC_TIME, LC_COLLATE, and other 
> capability, too.)
>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).  static binaries cannot benefit from the
	new engine though.

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

	i'm having trouble finding clear winner here.  i can understand
	both "with dlopen" option and "without dlopen" makes sense.

>> 	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.

	and again, what is the frequency of such an event?  and what is
	the possible upgrade paths?
	when we use "with dlopen" option, there can be couple of options:
	- add file into /usr/lib/localemod and get done
	- need a extension to localemod interface, replace libc as well as
	  /usr/libc/localemod/*.so
	when we use "without dlopen" option, the upgrade path will be like this:
	- install a new libc (without version number change).
	- recompile statically-linked binary

>(LC_TIME and LC_COLLATE needs dynamically loadable modules, too.)

	could you give me an example why glibc does not need it,
	and why we do need it?

itojun