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

On Wed, 4 Aug 2004 at 12:28:24, Matthias Sommerfeld wrote: > Dear Stefan, > > > 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. > > 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. > > Net_IDNA is not a wrapper, it's an implementation. Although it might be > "sexy" to have a transparent mapping of internal methods to the > extension ones. Yes. And I see that the "overhead" is quite low. It's just a question of design (API). > But as stated once in the list a few days ago - the premise for that is, > that both the PHP implementation and the extension (you are aware, that > there's more than one?) Yes! > 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. > - the same results > whereas the latter should be assumed. Should be :-)) > 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. > 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. > 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 :-)) Let's see what other think about the topic. (Though unfortunately it's already quite late, since the class in now in proposed-state --- my bad.) Regards, Stefan