That was 10 years ago. It is not necessarily a good precedent to follow. Quoth Larry:

Although the Perl Slogan is There's More Than One Way to Do It, I hesitate to make 10 ways to do something. :-)

I for one would like to see the current implementation of cpan:// changed to take advantage of a better search engine, rather than create Yet Another Shortcut type.

Yeah, search.cpan.org is quite terrible at "search". But metacpan is new (as far as I know). So my preference would be to make "cpan://..." turn into "google://site:search.cpan.org ..." and add metacpan:// in the mean time. At some point metacpan will seem unlikely to just disappear and cpan:// going to metacpan might be better.

- tye        

So then what? metacpan:// becomes simply an alias of cpan://? (though possibly vice versa under the hood)

Yes, search is also much improved over search.cpan.org, but it's the browsing experience improvements (and rapid development of new features) that have won me over. metacpan is a much nicer module and code browsing experience.

metacpan has sponsors for hosting, bandwidth, and DNS. So it is, at the least, not running on someone's personal machine. The project has had 57 individual contributors. I hope this bodes well for it staying around to the level of "permanence."

I see the parsing difficulty now, "what is needed to (do is to) create a new link shortcut" was not my meaning. I was hoping to ask "what actions are required to create a new shortcut? How are they defined, approved, etc. Where is the code?" I was curious as to what steps are necessary to create a new link shortcut.

I believe my question is answered further down, minus the implied questions of "what does shortcut code look like?" and "Is there a publicly accessible code repository for shortcuts and/or the perlmonks code base?" But with the addition of proof-of-concept code being written and submitted. Win!