http://qs321.pair.com?node_id=196133


in reply to Re: search.cpan.org comments/discussion
in thread search.cpan.org comments/discussion

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.

Replies are listed 'Best First'.
Re: Re: Re: search.cpan.org comments/discussion
by ignatz (Vicar) on Sep 09, 2002 at 13:06 UTC
    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.
    ()-()
     \"/
      `                                                     
    

      I think we're on the same page here. I'm proposing that a link on search.cpan.org would go to a node dedicated to the relevant CPAN distribution. That node would be 'owned' by an editor (kind of like dmoz categories) and would have structured content (XBEL could add real value here). The 'free-for-all' discussion would take the form of replies to that node - using the existing PM threads facility.

      Ideally the system would have some 'smarts' eg: if a person followed a link to the node for Test::Case and no such node had been created, then they would be presented with the node for the Test namespace instead. From there they might find links to Test::Simple, Test::More, Test::Harness etc with commentary that suggested when you might use one over another. Restricting that commentary to fit into an XBEL <desc> element would probably be beneficial - if there's more to be said it deserves it's own node or offsite link.

      I think having a dedicated node type that understands the 'standard' framework is important. Sure we could do all this with static HTML pages under personal accounts around the place, but if it ain't easy to maintain it won't succeed in the long term.