To publish on CPAN or not? And architectural q. on modules.

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I have written a module which facilitates the remote control of certain
amateur radio equipment (Icom radios). Now I am contemplatinmg publishing
them not only on my own website (TBD), but also on CPAN.

The questions I have:
1.) Is it worthwile at all? This module is useful only to somebody who owns
an Icom radio, attached to a local serial port. There is one similiar
module on CPAN, for another radio manufacturer (Device::THD7).

Further to this: there exists at least one or two libraries (non Perl)
like 'hamlib' and 'grig' which have a more general approach and try to
support remote control of many manufacturers radios, not only Icom. For
some reasons I choose no to participate in these projects. At least hamlib
has a Perl binding.

2.) How to make tests? Every single function of the module works only with a
radio attached to a local serial port. Not knowing a) if any radio at all,
or b) to which port, and c) which model is attached, I cannot make any
tests. Except some very general ones, which really don't tell much.

3.) How to name such a module? Following the above example (Device::THD7) I
could name it Device::Icom or so. Currently the module is named
IcomCIV::Radio, which is a general class useable for practically any model
of Icom radio. Later I will have specialized modules for specific radios,
named after the model like IcomCIV::ICR8500, IcomCIV::ICR75 etc. to support
special functions found only with these models.

4.) On an architectural question...
I have two supporting modules for IcomCIV::Radio, one which encapsulates the
low level serial IO (non-OO, using Device::SerialPort) and another (again
non-OO) which provides adress tables and general functions (like format
conversions) for the upper layer. Should these support modules go into the
main module or is it ok to have these as extra modules. Both are necessary
for the upper layer to function.

Many thanks,

Re: To publish on CPAN or not? And architectural q. on modules.

Ekki Plicht (DF4OR) schrieb:
Quoted text here. Click to load it

It nearly always is. For one, it gets people to notice your module.
Other benefits are the implicit bug tracking facility at CPAN
and the automated CPAN tests, which keep you aware of changes in
other modules or the Perl core that might otherwise (due to different
OSs/OS versions/compile time settings) not be obvious.

Quoted text here. Click to load it

If you feel your module has some unique qualities, chances are
big others might too. As long as you don't try to invent another
toplevel namespace, publishing would certainly be fine.

Quoted text here. Click to load it

Simply test as much as you can. use()ing the module has often
been enough to catch errors with CPAN testers. If there are
data conversions involved that use pack/vec or the likes, those
should be refactored to divide them from any input/output stuff
and testet with expected input and output, thus catching possible
mistakes on platforms that handle byte alignment, byte order or
type sizes differently.

Quoted text here. Click to load it

"Device" in itself is a bit generic. I'd probably prefer
HAM::Device::IcomCIV or HAM::Radio::IcomCIV to make it more
meaningful to the unititiated.

Quoted text here. Click to load it

If you're sure they are only helpful in combination with IcomCIV::Radio,
then package them together with that module.


Re: To publish on CPAN or not? And architectural q. on modules.

Christian Winter wrote:

[a useful answer]

Thanks, that helps me a lot.


Site Timeline