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

Dear Stefan,

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.

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.

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.

Same here.

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.

That strict and Registry dependend stuff would not make any sense on application level, where reliability comes first.

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

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.

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 never was against you :)

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?

Stefan

Matthias