All the Perl that's Practical to Extract and Report

CPAN Name Squatting

dankogai on 2006-05-01T08:44:16

CPAN Authors and Perl Porters,

I recently came across two cases of namespace squatting.

Case: Attribute::Memoize

That was taken by MARCEL but the module is missing. I guess MARCEL deleted Attribute::Memoize in favor of Attribute::Util which has the same functionality. But I don't like the idea of grab-bagging of multiple Attribute handlers in a single module so I mailed him what he wants to do with it. The mail was sent on April 8th and I got no reponse since then.

Case: Crypt::Camellia

That module does Camellia cipher for Crypt::CBC. The algorithm became open source only recently (April 13th) so it is almost impossible that the name space be registered by someone else. But it is registered by JCDUQUE. It is registered as RcdOg but once again the module itself is missing (naturally). Since JCDUQUE has registered Many Crypt:: modules, he did so assuming it will soon be available.

I now have a very strong doubt of module registration system. Do we really need that? And who and how the registration be processed is in the haze. I have requested to register Encode and Jcode before. Encode is even in core but those requests were simply ignored.

http://search.cpan.org/ seems to be taking more practical approach. Just index whatever does REALLY exist. So Attribute::Memoize and Crypt::Camellia belongs to me from its point of view. But once you fire up CPAN shell, it's registration that has te precedence.

I want some action be taken.

Dan the Foresaken by CPAN

We can rebuild it!

Alias on 2006-05-01T22:29:41

The PAUSE namespace is pretty messy.

And that comes about it's been humped at and abused for 10 years.

Lots of namespaces have first-come assigned, and those don't get cleared when they move. The module list provides additional metadata and a layer of officialdom

The modules@perl.org mailing list deals with corner cases and strange situations.

It has at times gone through unresponsive periods, but you shouldn't take that as an indication of it always doing so.

It has been fairly response for the last 9 months at least.

Take your case to modules@ and we'll fix it.

Let's be fair, please

brian_d_foy on 2006-05-02T04:22:05

CPAN, by design, wants people to upload things at the earliest time possible, even before stuff works in some cases. Get it out, available, and hackable by the community.

The gateway to that is the Perl Authors Upload Server (PAUSE). You just need a CPAN ID, which is pretty easy to get. You can then upload any module that you like, including ones with names already taken.

On top of that is the PAUSE indexer, which makes the CPAN meta files. It knows who uploaded what and which CPAN IDs get first right to a module name. Things like CPAN Search use these files to do their work.

To manage all of this, a group of volunteers do the human maintenance. I'm one of the volunteers, and I do most of the module registrations (with Adam Kennedy close behind). This use to be much more important because there was a "Module List", but we decided to kill that since the size of CPAN and the modern search services made it impractical and mostly irrelevant.

It looks like you sent tried to register Encode and Jcode in the spring of 2003. Unfortunately, I was off the net that year and couldn't register that for you. It also looks like you announced Jcode on the modules list before we had things automated. Sometimes life sucks.

We really have been working hard to respond to all requests, and it's a bit of a slap in the face to complain about something from three years ago to make it sound like that's still the situation. Please give us a chance to fix things before you spread false accusations. The who and how are very clear if you watch modules@perl.org for a couple of days.

Re:Let's be fair, please

Alias on 2006-05-03T04:12:51

Still, just because it isn't reasonable doesn't mean he has a point...

I'm not sure if there are any obvious steps we could take to make the situation any better though.

God knows I'd hate to have some web application or something queuing module requests. That would get out of hand pretty quickly. At least when something falls through the cracks on modules@ currently it doesn't hang around to slow things down later.

Is there anything you would suggest Dan?

Re:Let's be fair, please

Alias on 2006-05-03T04:14:16

That should have been

"Still, just because it isn't reasonable doesn't mean he doesn't have a point..."

Re:Let's be fair, please

brian_d_foy on 2006-05-03T04:18:40

His complaint would be more valid (but not really) three years ago. Even then, he could have tracked down a PAUSE admin and made a more direct plea. It doesn't look like he tried anything other than submitting the module registration form, so I don't think he really tried hard enough to make a statement about PAUSE other than his module wasn't registered.

Attribute::(Util|Memoize) namespaces

marcel on 2006-05-02T12:38:23

Guilty as charged; for the record, I've now made Dan co-maintainer of the Attribute::Memoize and Attribute::Util namespaces. Maybe I should actually give up the Attribute::Memoize namespace, since I've got no module of that name anymore...

Marcel