Thanks for the feedback.
I still think that CLI is needed in the name.
You are right that this is nothing more than a shell terminal, but in
the networking industry it is generally referred to as CLI; a Goolge
search for "Cisco CLI" or "Juniper CLI" or "Nortel CLI" yields the right
hit spot on.
This is what my module is targeted at. Yes, you could use the module as
a terminal for connecting to any Unix-like host, but there are usually
better ways of running commands on remote Unix systems, such as rsh or
SSH (without running an interactive shell on an SSH channel).
I do however like the idea of using "Control::"
The difference between the vanilla module and the AvayaData one is that
essentially the former provides read/write methods (as well as similar
functionality of Net::Telnet) while the latter uses these to build on
with cmd methods which automatically know what prompts to expect
(without having to set these) and other nice things like knowing what
escape characters to send to get to a CLI prompt at login; knowing how
to deal with output which is being paged by the switch, etc...
This will be well documented once I publish the modules. But basically
I'd like to just append AvayaData to whatever I name the vanilla module.
So I'm now leaning towards
Control::CLI
Control::CLI::AvayaData
Thanks
Ludovico
On 06/07/2010 13:55, Ben Morrow wrote:
quothludovicostev...@free.fr (Ludovico Stevens):
I have recently registered on PAUSE and have a module to upload to CPAN;
I need some advice on the Name Space to use.
I work with Ethernet switches& routers and I use Perl scripts to
automate tasks via the CLI (Command Line Interface).
Typically, the CLI of a switch/router can be accessed via any of Telnet,
SSH, or Serial console port.
For many years I used Net::Telnet, but more and more customers now use
SSH instead.
Typically a switch/router will only implement CLI over SSH in an
interactive shell, and Net::SSH2 has no capabilities to handle an
interactive shell like Net::Telnet does.
So I created my own module which presents a single consistent API and
can run over Telnet (using Net::Telnet), SSH (using Net::SSH2) or Serial
Coms port (using either Win32::SerialPort or Device::SerialPort); it
also provides all the necessary methods to deal with an interactive
shell regardless of the underlying connection type.
So if I make a script to automate a task, that script can easily work
across any of Telnet, SSH, or Serial access.
I have written a general module, which can be used against any device
from any vendor and can be re-used to customize the functionality for
specific product families; right now I have named it:
Net::CLI
I think I would call this Net::Tty, or perhaps Net::Terminal. 'CLI' is
not what I would look for here.
Since I work with Avaya Data (ex Nortel Enterprise) switches/routers I
also have a customized version which inherits and enhances the Net::CLI
functionality just for these products; right now named:
Net::CLI::AvayaData
It's not clear from your summary below how this differs from the vanilla
Net::CLI module, but I think the usual name for something like this
would be Control::AvayaData.
Ben
