Re: Please make up your mind about IDN-implementation!

On Wed, 4 Aug 2004 at 10:36:28, Matthias Sommerfeld wrote: > just a few comments on your post... Sure, very much appreciated. Especially from your side! > > first: I'm sorry for not having spoken up earlier. I know that wasn't > > clever - but also not possible due to workload unfortunately. > > > > Please have a look at my comment/vote > > http://pear.php.net/pepr/pepr-votes-show.php?id=124 and > > make up your > > mind about an IDN (internation domain name) for PEAR. > > > > We've talked this over already a while ago on pear-dev, and the > > results were implemented in the "temporary package" available at > > http://pear.speedpartner.de/. However, there were some > > things still > > left to do (support for libiconv as well as libidn, generally a bit > > more open API). That's why it was not proposed yet. Unfortunately > > David Rech is currently sick, but promised to finish his work very, > > very soon. > > > > Please make up your mind about the IDN-implementation that shoudl > > find it's way into PEAR. It's not a "use this or that"-discussion - > > > I'm just looking for the most extensible, open and support-able > > implementation. > > A few things pointed out by you in the Comment on your -1 vote include, > that my implementation lacks support for libidn, libiconv and UCS4. > > While UCS4 support was considered to be included a few days ago, I don't > see any advantages of ballooning the class further by adding support for > the various IDN extensions and iconv as well. > > Using iconv around the class is no problem at all, I think. > > I really prefer small tools, which do, what they are about to do. Not > more, not less. Supporting various encodings was a strong wish from people on pear-dev when we did a first pre-propose-discussion on the list. And if you cleanly support character-conversions (I consider the ISO-to-UCS4-conversion a bit of "hack" *g*) you need to use one of the existing extensions for that job. And this makes it necessary to support libiconv, in case e.g. mbstring is not present on that host. Using libraries, if present, was also highly appreciated - regarding speed. So if libidn is present, it was expressed that our class should use it (which I can understand). So if you need bulk-conversion of domainnames, installing the extension you can speed up the whole process, but still have a common API. It's like with e.g. a DB-wrapper - if you use it, it doesn't matter which underlying system you use. And if some things are not supported (here: if there is no libidn), the functionality will be handled in PHP. > > Afaik the proposal that's currently running is based on an > > implementation not by the package- authors, > > That's not true. Some *ideas* were originally borrowed from the C source > of JPNICs libidn. I ended up writing all the stuff by myself. Including > the tables... Ideas? Hmm, have a also had a look at the RFCs as well? Then maybe the copyright-statement at top of the source is a bit misleading - I thought you transfered the C-source to PHP (more or less strictly). > > and it's not designed following the RFCs. So I doubt that we can > > guarantee to really provide "support" for that implementation. > > That's clearly said not true. The only difference you notice is, that I > created replacement tables fitting the purpose: Replace by nothing just > means: skip that char. But the tables are quite long, split into several parts (imho unnecessary) and could be replaced by tables directly taken from the RFCs, which might make them a bit more fail-prove and allow cross-checking, imho. > If you do not see the place, were the input is splitted at the dots - > please look harder, it's there. Will do. If that's the case, sorry about that. Searched in various functions as well as searched for "split" etc. > > Comment are *very* welcome. (Please avoid flames!) > > Mission completed :) Thank you. Regards, Stefan