To publish on CPAN or not? And architectural q. on modules.
am 29.11.2007 18:56:43 von df4or
Hi.
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,
Ekki
Re: To publish on CPAN or not? And architectural q. on modules.
am 29.11.2007 19:51:54 von Christian Winter
Ekki Plicht (DF4OR) schrieb:
> Hi.
> 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).
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.
> 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.
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.
> 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.
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.
> 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.
"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.
> 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.
If you're sure they are only helpful in combination with IcomCIV::Radio,
then package them together with that module.
-Chris