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

Dear Matthias, On Wed, 4 Aug 2004 at 14:32:48, Matthias Sommerfeld wrote: > >>I don't get it. But this must be a translation problem I have here :) > > > > No problem, I'm going to explain that point further :-) Adding support for > > charsetes other than ISO and UTF8 (maybe also UCS4) is not such a big deal > > as you make it look like. But it allows you to easily plug the package into > > whatever szenario and encoding you might have at hand. > > The other point was: There is no real "performance loss" by doing such > > conversions, since you still are able to supply UTF8/UCS4 or ASCII directly > > and won't need conversions using an external lib. (Though it should be noted > > that C-extensions are immensely fast.) > > In the moment I am working on UCS4 support in string and array > representation. I see, this is useful. Fine. > >>Most poeple don't notice, that the "Internationalized" in IDN(A) just > >>means the contrary thing: It "nationalizes" domain names - a real > >>internationalization looks different to me. A punycoded chinese domain > >>name will not show up decoded correctly in a Russian only application. > > > > > > Depends. With Unicode this is theoretically possible, if you decode a > > name. > > Assuming, that Unicode is used. No big deal with up-to-date browsers. And there some international mailing- interfaces like JawMail (I use here) that use UTF-8 exclusively for frontend and email, since it allows to provide the best internationalisation. [...] > >>Let me explain my plans in the pre-PEAR era of the class. I intended to > >>make a core class handling the conversion stuff. Besides that I wanted > >>to build to more classes extending that core. > > > > Why separate classes for just a few lines of code more (but much more > > flexibility)? Aren't we in the situation of "I didn't need it, so it's > > not > > in there"? That has been discussed with several classes proposed to PEAR. > > That strict and Registry dependend stuff would not make any sense on > application level, where reliability comes first. Okay, I was thinking about universal charset-conversion using "what's available". > >>One should offer functionality for applications like PHlyMail, where you > >>are probably better off with no conversion than with no mail showing up > >>due to conversion errors. > > > > I didn't get you here either. With the API I have in mind and which David > > will work out during the day you can still use UTF-8 direct and don't need > > to convert charsets. But you have the ability to say "I need the funky > > [whatever] charset" and easily get it. That's the point. We shouldn't look > > at it too much from the European / American view only. > > If you deal with that funky charset in your application you will need > iconv anyway, since PHP itself does not speak Unicode in any useful way > by itself. Fully agreed. My point was just about being able to use several conversion- functions in your IDN-class. Would you favor to abstract the interface to the available characterset- conversion-libraries as well, since it might also be useful in other cases? > So offering input / output in UTF-8 / UCS4 seems the most sensible way. > > >>The other class should offer the strict mode for registration issues plus > >>Registry specifics (allowed characters and the like). Due to lack of time > >>neither of these is ready. > > > > A colleague of mine is working on such Registry-specific parts for a > > registration-robot. Maybe I can persuade hin to provide it as a > > PEAR-package. > > That'd be great. I'll follow that path, as soon as the class has enough domain-checks available. > >>But this just touches the borders of the current question, whether > >>including checks for present extensions are useful. > > > > Checks are definitely out of the bounds for a conversion-class, I totally > > agree with you here. It's too specific and is too much work if you intend > > to support "all" domains as well as keep it up to date. But using > > extensions for encoding/decoding and charset-conversion was the point. > > I agree regarding the mentioned UCS4 capability I am working on. > If there'd be just one libidn extension, I'd be fine including hooks to > it. But what about the other at least two ones with different APIs? > Ignore them, although they are better? Include them? What, if someone > else comes up with another, extraordinarily good IDN extension? I hat > dependencies, I cannot influence. This is one of these. In my opinion. Support that as well, open API. [...] > > The class that we already proposed was developed with PHP4 in mind. David > > is currently working out the API and promised to have a complete package > > for discussion by this evening. He also promised to specially make sure > > that it's PHP5-forward-compatible. > > So you will come up with a competing IDNA implementation today? It's based on the implementation already available at http://pear.speedpartner.de/ for some time now and which has already been discussed on pear-dev. Refering to the devs at that time just "a few things should be added" before proposing it. And that's what David volunteered to do. I've heared from him a few hours ago and he really, really promised to provide a complete package by today evening. Let's see ;-) Kind regards, Stefan