Re: PEAR Account Request: dr

Stefan Neufeind wrote:

On 8 May 2004 at 18:40, David Rech wrote:

Stefan Neufeind wrote:

On the one hand I think that it might simply go into the current package I18N as a separate class/file. Another solution I can think of would be I18N_Punycode. But to my understanding it's more tied to internationalisation (or charset-conversions) than real "Net", isn't it? Stefan

I agree on I18N_Punycode. Maybe we should add the Stringprep stuff as I18N_Text, I18N_Characters or something like that to the existing I18N package? This would add character mapping to the I18N package. Stringprep with its character mapping could be usefull for I18N related things other than Punycode anytime later.

Well, you need quite large tables for complete Stringprep-conversions strictly according to the RFCs. Currently I only have the Nameprep profile implemented and the tables needed for this to implement it fully. Even these are quite large. To make them smaller and faster to load they are currently stored in serialized format in my package. Since nameprep is afaik only used in conjunction with punycode I'd propose to simply have them as private functions inside the class, for now. If need arises we can at a later step simply separate it to a separate package (because of the large tables). I'm against adding that burden to the I18N-package. Stefan

Oh yes, these tables are *evil* large. I've divided mine into file/array pieces. Serializing is quite a fine solution, I think I'd follow on that and review my stringprep code again. Summarized we have two ways to take: a) I18N_Punycode for pure punycode en-/decoding, plus I18N_IDN for the idn_to_*() functionality. or b) One single I18N_IDN package for all related things to that. I'd say b) would be more reasonable than a), because ATM there's no really need for the mapping abilities build around the IDN. I'll hurry up to compare our two solutions ASAP. -- David Rech