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

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.

I don't get it. But this must be a translation problem I have here :)

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.

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. And the whole algorithm is purely specified for domain names. So I think, I18N is not the home of IDN :) Just my 2 cents on this.

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. Let me explain my plans in the pre-PEAR era of the class. I intended to make a core class hanlding the converiosn stuff. Besides that I wnated to build to more classes extending that core. 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. 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. But this just touches the borders of the current question, wether including checks for present extensions are useful.

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. :)

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.

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.)

Yeah!

Regards, Stefan

Regards, Matthias