I was only talking about curators of the information about the
modules, not curators of CPAN. That sounds like far too nasty a job,
and as has been said, it has already been hashed and rehashed ad
nauseum.
We also can't go enforcing rules about namespace - the (non-CPAN.pm
indexed, search.perl.org) namespace is already pretty much raped. All
you can do as an author is boycott badly named modules / re-release
them under a more correct name :). The indexing should follow the
community, not define it.
Also, some people seem to have in their minds no distinction between a
distribution name, and the name of the module. They are independant.
For instance, the Compress-Deflate distribution could install
Compress::Deflate, which provides raw entry points to the commonly
described algorithm, Compress::Gzip, which provides Perlish wrapper to
Compress::Deflate and the Gzip header format, and Compress::Zlib::PP,
which emulates the Zlib interface for legacy code... indeed, in the
future it might also install a compatibility stub at %Compress::Zlib::
that the installation of the "real" Compress-Zlib distribution
replaces. I said could, not "the forthcoming release of
Compress::ZlibPP ought to". It's just an example.
In summary;
- the Distribution refers to the _implementation_ and may be
completely different from the delivered modules (eg, libwww)
- the name-space chosen for the installed modules refer to the
*API*
- unfortunately, currently it is not possible for more than one
module deliver the same API - except by carefully arranging @INC
Once you have changed the API of a module significantly, you should
really be releasing the new API in a different name space. As there
is a current lack of a clear, *widespread* notation for requiring an
API version, this is a sensible strong suggestion to module authors,
especially for modules that are expected to be in heavy use. [unless
you already used the API version API in your module's Synopis' API,
then you have the freedom]
This practice is followed for long-standing and core modules, of
course. Just ask Tim if he'd consider enhancing the DBI API and
releasing it as a backwards-incompatible DBI 2.0.
I think I've just re-defined my mapping exercise to mapping APIs and
not distributions. But as an AP, it's the I that you're interested in
anyway - and AP's are the primary target market of this information.
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)
The rich will do anything for the poor but get off their backs.
KARL MARX
