module namespaces on CPAN...

gU5t4F gustaf at cmetech.com.au
Fri Jan 16 00:08:16 CST 2004


Hiya all,

i wish to upload a bunch of modules to cpan, but in light of the notes
they have for contributors i am wondering (/and/ talking) about
namespace before i do anything silly ;)

the modules i initally have to upload are a bunch of modules for
remote computer control of Uniden radio frequency scanners. Now there
seems to only be one module relating to Ham radio on CPAN currently
and that is Audio::Radio::V4L which does some very basic stuff for RF
receiver control via /dev/radio.

now i have several problems with the namespace chosen by the author
of that module...

i)   the "Audio" top level. While this is where the author's headspace
     is (he has contributed a whole bunch of other modules to CPAN -
     all dealing with streaming [audio] radio over the internet),
     whereas primarily i am interested in radio frequency as the
     transport for transmission of data comms. "Audio" does not sit
     comfortably with this and 'gives the wrong impression' by my way
     of thinking.

ii)  the "V4L" part. The guidelines on CPAN suggest that no short
     names should be used unless they are /really/ familiar terms. I
     do not consider "V4L" (which incidently stands for Video4Linux)
     to be in the really familiar category.

anyway, locally (on my workstation at the lab) i have been doing
development with the following simple namespace:

Uniden
Uniden::UBC780XLT
Uniden::UBC785D
.
.
.
Uniden::PRO2052

this structure is important in that i have all the Uniden scanner
protocol stuff implemented in Uniden.pm and then a .pm for each model
of scanner that implements model-specific stuff and uses overloading
to specify the feature set a particular model is capable of. This
works really well, but...

what about namespace on CPAN? At some point i would like to see if i
can genericize what i have written to make it useful for other RF
receiver hardware (such as ICOM and Yaesu comms receivers), but there
will always be a heavy amount of proprietry stuff as that is the
nature of the protocols used by the hardware manufacturuers (and hence
the real need to have a "Uniden" namespace). To put this stuff on CPAN
there needs to be higher levels of namespace defined. Ideally
something like:

    RF::Scanner::Uniden::UBC780XLT

but we run into the 2-letter issue. Also "Scanner" could probably be 
somewhat more generic so perhaps...

    Radio::Receiver::Uniden::UBC780XLT

which i think is fine, although perhaps..

    Ham::Receiver::Uniden::UBC780XLT

"Ham" is good as there is no confusion about what context of "radio" 
we are dealing with. Debian uses "hamradio" for namespace of similar
software in their packaging system :)

    HamRadio::Receiver::Uniden::UBC780XLT

down the track i would want to upload a bunch of modules for encoding
and decoding computer generated radio transmissions (perhaps
HamRadio::Codes or HamRadio::Code::Baudot etc) and probably some
general libraries for calculating radio-related stuff (HamRadio::Math?
HamRadio::Calc?) and so on. I guess at some point (after i get my
amateur radio licence) i might even get into the Tx side of the hobby
and end up with a bunch of HamRadio::Transceiver::* modules

If i follow the namespace already defined on CPAN my modules would end
up like this:

    Audio::Radio::Uniden
    Audio::Radio::Uniden::UBC780XLT
    (etc.)

which i really don't like. There is no differentiation between
receivers and tranceivers and there is that irritating "Audio" out the
front, oh, and the context of "Radio" is not clear. *sigh*

so what do i do now? Is it too late to change the namespace on CPAN?
What is the best way for me to present my case and who do i present it
to?

L8rz,
Foobard - Jester from the Court of Chaos




More information about the Melbourne-pm mailing list