Re: metacpan link shortcut?
by davido (Cardinal) on Jul 12, 2011 at 00:44 UTC
|
There are three options: Point [cpan://.....] to metacpan, add [metacpan://......], or wait and see if if the new sensation (which seems cool but does say "beta" in the top right corner) has the staying power and real-world popularity to become at least nearly as ubiquitous as search.cpan.org.
It might not hurt to add yet another link type, but there's the question of whether it will get used enough to justify the work. That could be proven here as a test bed, or the the Monastery could take the wait and see approach. I don't know which is better in this case. Perhaps it is a topic of discussion for cabal based on the response in this thread.
I do suspect that the notion of redirecting [cpan://...] to the metacpan site would probably not happen as it would alter the behavior intended by the authors of thousands of existing PerlMonks posts.
| [reply] [d/l] [select] |
|
the Monastery could take the wait and see approach
I'm in favor of that.
it would alter the behavior intended by the authors of thousands of existing PerlMonks posts.
If that were an effect of the change, I would definitely oppose it. But I don't think it would be. cpan:// searches for the terms. It does not create deterministic links to specific pages. For that, we have mod:// and dist://.
I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies .
| [reply] [d/l] [select] |
|
It might not hurt to add yet another link type, but there's the question of whether it will get used enough to justify the work.
Surely the work is trivial enough to need no justification
| [reply] |
|
Ok, a brief patch has been submitted. It now comes down to whether the patch is considered adequate, and whether the idea is considered good in the first place. We'll see what happens. If it gets applied the docs will be updated and a brief announcement may be made.
Update for clarification:
The patch creates a [metacpan://module::name] or [metacpan://] tag. The first goes directly to the module being requested. The second just goes to the metacpan.org home page. After a patch is submitted it usually has to go through a sort of informal review process by others in pmdev, as well as the gods. pmdev cannot apply a patch once it's been submitted though, only the gods can (not to throw anybody under the bus; just explaining the process). The patch could possibly never get applied for any of a number of reasons, including but certainly not limted to:
- It might be deemed inadequate (may fall short of solving the complete problem).
- It might be determined to contain bugs.
- Someone else may come up with an even better patch.
- It might be seen as something that could increase server load (though probably not in this situation.
- It might be seen as missing the mark; maybe a [metacpan://...] tag isn't as desirable as changing the [cpan://...] link behavior, for example.
- Maybe there will be hesitation as metacpan.org is still in beta status. Since we don't know what beta means in this case, it could be inadvisable to suddenly dump additional load on the metacpan.org servers. Maybe beta means it's running on someone's computer in their basement over a DSL link. Maybe it's just a side project on a server that couldn't handle the load. Maybe it has any number of reliability issues. Until we know what 'beta' means, we don't know how much the Monastery should rely on it.
- Adding to the previous thought, if the "right thing to do" is to change the [cpan://...] tag behavior, and yet we're hesitant to do so because we don't know about the reliability of a beta website, it doesn't make sense to roll out a [metacpan://....] tag now, only to pull it back and alter [cpan://....] behavior later once metacpan.org comes out of beta status.
So there are real reasons for not jumping too early at implementing a new feature. A patch has been submitted as a sort of 'proof of concept', but that doesn't mean the concept has come of age just yet. Maybe someone could jump who is a little more senior than I, to provide insight. But until then let's just be patient and see what happens. :)
| [reply] [d/l] [select] |
|
|
Re: metacpan link shortcut?
by Juerd (Abbot) on Aug 31, 2011 at 13:46 UTC
|
| [reply] |
Re: metacpan link shortcut?
by jgamble (Pilgrim) on Nov 07, 2011 at 20:40 UTC
|
I'm really not thrilled with the idea of one of my tools being superseded by an alternate mechanism. MetaCPAN search should have its own keyword. Who's to say that CPAN's search mechanism will remain the same in the future?
| [reply] |
|
Well, one of the fundamental points of having a shortcutting mechanism (like [cpan://Fisher-Yates]) is to let the user specify a search of arbitrary exactness without worrying about the implementation. If you know exactly which module or dist you want, you should be using the [mod:// ] or [dist:// ] shortcut instead. And if you want maximal determinism in the links you post, just use the exact URL.
Indeed, we've switched the implementation of [doc:// ] once or twice over the years as the "canonical" website changed. Existing links should still work pretty much as intended. And for the few old ones that do break — well, them's the breaks. I think we do a reasonable amount of due diligence to not excessively break old nodes, but really there are no guarantees.
I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies .
| [reply] [d/l] [select] |
Re: metacpan link shortcut?
by Anonymous Monk on Jul 12, 2011 at 00:10 UTC
|
What is needed to create a new link shortcut
Yes, but how? Show an example :)
or update the current search.cpan shortcuts to go to MetaCPAN.org
kobesearch:// did not replace cpan:// , so metacpan:// probably shouldn't replace cpan://
| [reply] |
|
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.
I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies .
| [reply] [d/l] |
|
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.
| [reply] |
|
|
|
|
|
|
>What is needed to create a new link shortcut
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!
| [reply] |
Re: metacpan link shortcut?
by metaperl (Curate) on Nov 02, 2011 at 14:02 UTC
|
'metacpan' is too long to type.. I vote for [mpan://resource]
| [reply] [d/l] |