Mark Leisher <[EMAIL PROTECTED]> writes:
> Ed> I haven't seen your engine, but I've created such engines and worked
> Ed> on engines others have created. They aren't easy to do. Just
> Ed> supporting a basic set of Internet encodings will be a difficult
> Ed> undertaking. Maybe you've got it all worked out, in which case hats
> Ed> off to you. Otherwise I would recommend a strategy whereby you
> Ed> implement a core set of single-byte conversions (for, say, Western
> Ed> Europe, Central Europe, and Cyrillic languages) with an internal
> Ed> engine and plan to incorporate an optional ICU hook-up for anything
> Ed> else. That way you don't have to maintain and distribute large Asian
> Ed> encoding tables.
>
> What would be nice is some variation of Bruno Haible's libiconv that allows
> dynamic loading of mapping tables. Then Perl would have reasonable conversion
> capability at about 1/16 the size of ICU.
Well, I'd go beyond this and say that it would be nice if Perl would use
the system iconv when available - iconv isn't the greatest interface,
but it is generally pretty workable, and if people use the system
capabilities, then you avoid an explosion of tables.
The question here, of course, is whether:
- Perl behaving the same Perl on every system
or
- Perl behaving the same as other programs on a given system
Is more important. It might be necessary to only use the system iconv
on a known set of systems; I believe the GNU iconv data is kept in
sync with libiconv.
Regards,
Owen
