[Mono-dev] Replacing/Removing I18N

[Paolo Molaro]

On 10/09/06 Andreas Nahr wrote:
> Current situation:
> I18N is located in multiple separate assemblies that contain encoding 
> classes that are autogenerated. The single-byte encodings (my current 
> focus) use a potentially big CASE-Structure to compute the output.
> 
> Problems:
[...]
> Considerations for change:
> * Data must not be in private memory but shared as much as possible 
> (currently most is shareable)
> * If possible avoid internal-calls and other direct runtime-support 
> (currently does not need any)

I'm all for dumping the current I18N assemblies, the problems you list
are real, we just need someone to write and test all the code.
What I don't agree with is avoiding internal calls and runtime support.
The reason is simple: the most efficient way to export to the manage
world arrays of data is to have them as C arrays in the mono runtime or
as data files that mono loads and mmaps, returning a pointer for use in
usafe code in the assembly implementation. See the locale data for
examples. I18n tables are best put outside the mono binary, usually
(except latin1 support). The aim is to optionally move outside also
other tables that are currently hardcoded inside mono.
Note: resources in assemblies are mmapped, but still using datadirectly
from mono is more efficient.

A small comment of your considerations, though: using a 64KB table when
a much smaller one is sufficient would be a waste. We need to keep in
mind also disk-space issues.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better