Re: search.cpan.org comments/discussion
by ignatz (Vicar) on Sep 09, 2002 at 00:35 UTC
|
I've had the title "The Annotated CPAN" swimming around in my head for a while now. Something that pretty much does what you're talking about. Between USENET, Perl Monks, and other Web Sites out there one could come up with a pretty hard core resource. (FYI, I am a fanatic when it comes to cataloging things. My all time hero is Ludwig Von Köchel, the guy who fanatically cataloged the works of Mozart.)
Here's a couple of things that I would add to what you have said:
- Book References
- Cached Usenet posts, edited
- Link to the latest version of each module, as opposed to the raw search results that one gets now.
I should say that I'm pretty pleased with the new version of search.cpan.org but there's no reason why the community can't do more...
++ for bringing this up!
()-()
\"/
`
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
I got an email reply from Graham Barr that this format link
does work: http://search.cpan.org/dist/libwww-perl. From the PM side, there are a couple of gotcha's:
- you have to use the distribution name which might not be the commonly used name (eg: libwww-perl rather than LWP
- you have to remember that distribution names use hyphens
rather than double colons (eg: XML-Parser)
- don't forget about case sensitivity
Given all this, it's not hard to see why the [cpan://name] links go to the search function but if you get the module name wrong (eg http://search.cpan.org/dist/xml::parser) then search.cpan.org falls back to search mode anyway.
So, perhaps the implementation of the [cpan://name] links should be fixed to change '::' to '-' and then point to search.cpan.org/dist/name
| [reply] [Watch: Dir/Any] |
|
|
|
| [reply] [Watch: Dir/Any] |
|
Re: search.cpan.org comments/discussion
by erikharrison (Deacon) on Sep 09, 2002 at 01:41 UTC
|
I see a huge benefit to this. It is unfortunate that it's not a good idea (in its current form at any rate).
The problem is that if the service became useful the the server load would become enourmous. Too much, I think, for the Monastery to handle.
Secondly, I think that there is a huge amount of material already out there that would be of great use to such a catelouge. An optimal discussion area would leverage this information, which would only vastly increase space, or else suffer from the Sea of Broken Links effect, as we tried to point off-site.
Thirdly, I see a potential for the growth of implementation discussions. Here we begin to see a slippery slope - there are huge benefits to discussing implementation details, both as a learning resource for implementors and as a knowledge base for potential users (after all, knowing that Secure::Module::Which_Does::Encryption::Stuff uses a cruddy xor algorithm could be very useful to a user!). But at what point would we cross into a "go to the LWP list" mode? How do we contain such discussion to make it maximally useful and not split between here and the varous mailing lists?
Finally, the organizational structure of Everything may (though I'm not sure) be suboptimal for such a structure. Free association is fundamental to the way the Monastery works, but not so for such a resource.
What would be nice would be a human organized catalouge of the CPAN. But who would volunteer for this job? Well, perhaps me, but don't quote me, and Jarkko has enough on his plate :-).
Cheers,
Erik
Light a man a fire, he's warm for a day. Catch a man on fire, and he's warm for the rest of his life. - Terry Pratchet
| [reply] [Watch: Dir/Any] |
|
The problem is that if the service became useful the the server load would become enourmous. Too much, I think, for the Monastery to handle.
Do know it would be to big a load for the monastery? Could we not just throw more hardware at it if it became a problem (assuming a sponsor could be found)?
at what point would we cross into a "go to the LWP list" mode?
excellent point, I meant to include 'links to relevant newsgroups and mailing lists' in my original list - I'll go back and do that now. I was imagining that the main page people came into would be a special node type that allowed for all this structured data.
My initial thought was that we should add a threaded discussion capability to search.cpan.org but then I thought 'wait a minute - that's exactly what Perl Monks is already!'. Hence my suggestion of more closely integrating the two sites.
| [reply] [Watch: Dir/Any] |
|
I personally think that a free-for-all PerlMonksesque threaded discussion would be of less use in this context. I do like the idea of having a node devoted to a specific CPAN module, but that's not the same thing as an editor doing the research to present a focused presentation of what's available out there.
Right now I use the XBEL Bookmark Exchange Language to store this kind of information. There are a couple of things that I would like to see added to the specification (multiple URLs for a "link" to support google cached docs for one), but it's perfect for storing most of what such a site would need. There's even a CPAN module to display it.
What I would do would be to designate editors for specific areas (Crypt, HTML, etc) and have them organize resources around their areas in an XBEL XML doc. Than the editors can fold their additions into the master documents displayed on the site. I would start with registered modules and then work down to stable ones from there.
Here's a proposed XBEL folder structure for a specific modules:
Name
Description, including platforms supported
- CPAN Module Link
- CPAN Author(s) Link
- Home page for the module
- Tutorials
- Discussion
- Perlmonks
- Usenet (Probably goggle as a simple start)
- Websites.
(I've already written a column on that, etc...)
- Useful modules that use it.
(This way one can point to specific code samples from the CPAN.)
- Alternatives with pros and cons to them.
- Dependencies (not just modules, but libraries and applications such
as Apache/mod_perl or GD)
It would be no big woop to set up a display site on one's Perlmonk server account (one of the reason's I asked for one, actually). Hell's bells, I may just start doing this today. Let me know what you think.
()-()
\"/
`
| [reply] [Watch: Dir/Any] |
|
Re: search.cpan.org comments/discussion
by tjh (Curate) on Sep 09, 2002 at 21:27 UTC
|
An Annotated CPAN would be nothing short of wonderful.
Just on a quick think, it would be really fun if it (ACPAN) had:
A flag indicating if the subject module was in core distro. (Which version and distro)
How many times this module version has been downloaded (marginally useful, but interesting),
some form of rating so one could know "is this a respected and tested module?" especially if I'm unfamiliar with the module's subject domain (and so I don't have to almost reinvent wheels to understand it...),
A broken out set of discussion areas for each module including: bug reports (you know it'll happen here too), implementation disucssion, Documentation discussion, Author's Announcements (subscribable? email?), etc.
grantm, ignatz, erikharrison all have good ideas about this too.
It's true that I already dig up much of this data by spelunking a variety of sources, and I know that some of what I've listed is partially fulfilled (SourceForge, PM, CPAN itself, et al). However, I often find all the searching and researching tedious and sometimes quite time-consuming. Yes, it's still Much Faster than rolling my own... :) CPAN is priceless already.
Should it be a separate site? Should it really be part of CPAN itself? I dunno. The community has certainly benefitted from the various sites supporting Perl, so maybe it's not a problem to have another.
It would be terrific if the problem (if there is one) was Fully Attacked by people smarter than me (said 'people' should be remarkably easy to find :) ±0.02 | [reply] [Watch: Dir/Any] |
Re: search.cpan.org comments/discussion
by Solo (Deacon) on Sep 12, 2002 at 01:47 UTC
|
I'm excited about a PM-inspired 'reputation' or 'XP' attached to every CPAN module (proposed by tjh above) with or w/o full-blown discussion! Consider some of the benefits:
- allow everyone to promote their fav modules
- inspire mod owners to improve their work for (documented, statistical) reward and recognition
- provide an indicator of the quality/usability of each mod for those unfamiliar w/ them
- provide a 'roadmap' for those wishing to learn new modules (highest to lowest reputation)
- provide a reference for CPAN admins if pruning decisions ever become necessary
Others surely can think of more...
--
May the Source be with you.
You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.
| [reply] [Watch: Dir/Any] |
|
Yes, a rating/poll would be very cool. Eg:
261 people have rated this module. Average rating 4.2 out of 5
We could eschew the standard stars ratings and award camels instead!
| [reply] [Watch: Dir/Any] |
Re: search.cpan.org comments/discussion
by fglock (Vicar) on Sep 09, 2002 at 20:35 UTC
|
The PODs already can have links
to websites (many point to sourceforge
or author's pages).
An author could just point to
a PM node. Then it will be a matter of
automating the link
collection and make an index.
IMHO we need an RFC on how to do
the linking. For example, a standard
=Links POD section.
update: dead links might be tested and filtered
out by the indexing program, maybe.
| [reply] [Watch: Dir/Any] [d/l] |
|
Yes, links from POD to FAQ's and the like are definitely useful. One limitation of POD is that the module author controls it. If you're looking for opinions on the merits of one module versus another, a discussion forum is invaluable.
Another problem is the overhead of keeping it up to date. If you just want to add a link, editing the POD, updating the Changes file, rolling up a new tarball and shipping it up to CPAN makes for a significant psychological barrier.
| [reply] [Watch: Dir/Any] |