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

On Wed, 4 Aug 2004 at 13:30:02, Matthias Sommerfeld wrote: > >>>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. > >> > >>BTW: I will look into the topic of including direct support for UCS4 in > >>string and array representation today. It shouldn't be that complicated.. > >>And it makes sense, definitely, especially when having a look over to: > >>http://pear.php.net/pepr/pepr-proposal-show.php?id=131 > > > > Fine. But I can't see the point of adding interfaces to other charset- > > conversions as well (see below). If you get prepared input in UCS4 you > > surely don't need to convert anything. But I would be able to easily use > > it in whatever app / encoding I might have. > > 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.) [...] > >>offer > >>- the same API > > > > I don't think so! Net_IDN (or whatever it's name might be - I'm more in > > favor of relating it to I18N) has it's own API. And whatever extensions > > are there or what might come up (different/faster/... implementation) > > you would be able to use it by calling your functions. Makes it a bit > > slower, surely, in contrast to calling the API directly. But you have a > > consistent API. > > 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. > And the whole algorithm is purely specified for domain names. So I > think, I18N is not the home of IDN :) Thats up to discussion, yes. But it's also still to be discussed if it's Networking-related, since you don't deal with a Networking-stack at all :-)) However, that's a point of mior discussion to me. > >>I think, this topic is more of a general issue - include all possible, > >>sensible functionality into the class turning it into a monster class > >>(ACME - a class making everything), > > > > It's not that much of a "monster" as it may sound! > > > >>or put adapter classes around it for transparent handling of either > >>Net_IDNA or ext/libidn. > > > > Yes, but having the implementation as the major part of the class (refering > > to lines of code etc.), there is just little more work to put a "extension > > present? use it!". And I don't think that another class on top or even > > another package for that purpose makes much sense. > > No, not another package. :-) That was the intended reaction. You got the point! > 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. > 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. > 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. > 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 assume, that people, who have any of the extensions installed, won't use > >>Net_IDNA. > > > > I think you assume right and wrong both at the same time :-) You are right, > > if you refer to the individual solution for one company running it on > > their systems. But PEAR has always aimed to be as portable as possible > > (php4 and php5 etc.) if that's not too much of a performance-issue. And > > here it wouldn't. > > The "wrapper", as you call it, would allow any application written using > > the class to get the maximum possible performance and still stay > > environment-independent. Otherwise, surely, you would use libidn > > directly. > > Good point. :) Excellent. So you're on my side? :-) > >>I call for input from others here on the list about that. > > > > > > Really hope so! > > > > [...] > > > > > >>P.S.: Regarding the PHP4 implementation, please have a look here: > >>http://idnaconv.phlymail.de > > > > > > Why not make your class compatible? I don't see the point in it! It's > > easily possible, if you really want to :-)) > > I don't say it isn't. The question is: How to deal with it? Propose both > Net_IDNA (PHP4) and Net_IDNA2 (PHP5)? Any other ideas? I am unsure, > that's all. 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. Stefan