Skip Menu |

This queue is for tickets about the Encode-Punycode CPAN distribution.

Report information
The Basics
Id: 29240
Status: resolved
Priority: 0/
Queue: Encode-Punycode

People
Owner: Nobody in particular
Requestors: CFAERBER [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



At the moment, I'm in the process of cleaning up all of the IDNA-related modules; I'd like to release a Net-IDN-tools v1.00, which contains all of the IDN-related modules, soon. May I ask for permission (co-maint) to include Encode::Punycode in this release, too.nstable API? I would like to rewrite it to be based on Net::IDN::Punycode, bypassing the IDNA::Punycode module, which, unfortunately, is not as robust as it should be (see http://rt.cpan.org/Ticket/Display.html?id=16144). Claus
On Sat Sep 08 19:55:58 2007, CFAERBER wrote: Show quoted text
> I would like to rewrite it to be based on Net::IDN::Punycode, bypassing > the IDNA::Punycode module, which, unfortunately, is not as robust as it > should be (see http://rt.cpan.org/Ticket/Display.html?id=16144).
Hi. I've finally found some time tending after my perl modules. I'd still like to include the module in N::I::Encode v1.00. Claus
I've uploaded a new version of Encode::Punycode. It's still a separate module for the following reason: It does not really make sense to have Punycode as an Encode plugin. Unlike other encodings, Punycode can only encode short strings but not full character streams, so it can't be used with PerlIO or for "use encoding". Writing encode('Punycode', $string) has no advantage over encode_punycode($string). Keeping the module around for compatibility makes sense; including it with every installation of Net::IDN::Encode does not.