Re: More 6PAN musings: local namespaces

> This is a
> solvable problem.  We shouldn't just throw up our
> hands based on past
> failures.

In all humility, here is my proposal:

I am not a frequent contributor to this list, just a
Perl programmer who doesn't want to learn Java. :) 
Now that Perl 6 will become truly object-oriented, the
only reason to use Java (besides Java being the only
computer language you have ever heard of besides VB)
is the coherent and excellently designed module system
that Sun has come up with for it.  I think the debates
about CPAN can be the beginning of a redesign that
might lead to a new, comparable approach for the Perl
libraries.  

So, in order for me to avoid learning Java, I propose
that a CPAN "Curation Project", or an Extended
Standard Perl Library",  be formed.  

First of all, keep CPAN the way it is -- a central
unstructured location to put modules that the
community may be interested in.  It works fine for
that currently.  However, its unstructured character
makes it difficult to base business and other
organizational solutions on it.  Furthermore, creating
an automated system that will magically make it into a
structured, predictable, coherent library is, I think,
impossible, no matter how well designed namespaces (or
whatever other solution) might be.

To address the shortcomings of CPAN, then, we add a
layer of indirection--an "Extended Standard Perl
Library", an evolving software tree based on modules
first loaded in CPAN that have been gathered,
standardized, and tested by a group of Perl hackers. 
This library should be highly managed, by real people,
in order to give it the coherence and predictability
that CPAN lacks.  The contents of the Extended Perl
Library should be evaluated not only on their
usefulness and robustness,  but also on their lack of
duplicated functionality with other modules. 
(Perphaps the "standard" library should be confined to
duplicating or interfacing the standard C library,
while extensions to that would be part of the extended
library.)  The old CPAN would still exist and would be
the first place that a module would be available for
the community; once the Extended Perl Library hackers
decided the module is appropriate as a general
solution, it would be moved into the Extended Library
pipeline.  

Perhaps a pipeline could be CPAN -> Nominated ->
Unstable -> Testing -> Standard.  New versions of an
already accepted module that don't break interface
would come in under Unstable.  If modules broke
interface, then they should be put into Nominated. 
Modules that the group has not evaluated would come in
under CPAN (i.e. "register and upload"). Although some
module writers may feel this cramps their style, we
all must sacrifice for the greater good sometimes.

The library should adopt tools like Debian's "apt" to
keep local copies updated automatically, perhaps on
demand (when you say "use foo", check to make sure
"foo" is current, download if not, etc).  

Such an Extended Library might also be a step toward
an application server approach (did you catch the plug
for making all Extended Library objects serializable
through some inheritance mechanism?).  

Here is a possible rough roadmap:  sift through CPAN
and come up with a map of the functionality sets of
modules provide and a map of the modules that provide
them (e.g.--"parsing HTML" is a function,
"LWP::whatever" is a module providing that
functionality).  Identify the best modules to provide
each function.  Also identify functionality not
addressed anywhere in CPAN (probably very little). 
Create a subset of CPAN from the modules selected,
then evaluate the modules this subset contains for
interoperability and predictability.  This evaluation
will probably include deciding to delete some
duplicated functionality from modules or moving
functionality to more appropriate places; it will also
include creating consistent naming and parameter
schemes for maximum predictability and modifying the
modules to reflect these changes.  At times it may
involve merging two or more modules to make a third,
better, module.  Additionally, create new modules that
address gaps identified earlier.  Then package it up,
test, download.  (I make it sound so easy...)  I think
a few central people could do the evaluating and
mapping of CPAN as a whole, but modifying the modules
to fit into the new scheme should fall to module
maintainers. 

Of course, the decisions about contents and interfaces
should be made democratically.  The organization of
the people who work on this Extended Library could
probably be based partly on the Debian project, which
essentially performs the same role for a much larger
set of software (with the important difference that
Debian offers multiple solutions to the same problem,
which the Extended Library should avoid). Current
module maintainers/writers would make excellent
charter members of the Extended Library organization. 
At all points, Extended Library decisions would be
made by concensus or vote.  

So, please respond with your, ahem, responses.  I am
willing to offer any help that I can. I am sorry to
jump to the discussion with such a long rant, but I am
afraid that the solutions to The CPAN Problem have so
far concentrated on finding automatic solutions (like
namespaces) to problems which require human
intervention, planning, and creativity. 

With thanks and respect to the Perl Community,
W


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com