%commands vs. @commands

[Ed Ravin]

On Wed, Jun 08, 2005 at 12:39:30PM -0400, Andrew Partan wrote:

> As it is, we currently have 12 *login programs and 23 *rancid
> programs; most of which share a fair amount of code.  Trying to
> keep them in sync & trying to make sure that changes that works on
> one doesn't blow up another is a pain.

And I just added another *login program, and will release hp4000m.rancid
and hp4000m.clogin shortly. :-(

> I think Heas' comment of working on the configurable rancid is the
> way to go - fewer commands for us humans to remember; more smarts
> in the code.

What would such a configurable rancid look like?  Here's one vision:

We have one *rancid program.  It has a series of device-specific
"plug-ins", implemented as Perl modules.  The modules are separated into
generic code (like ProcessHistory) and vendor-specific or device-specific
code (like processing config output).  Maybe you can get fancy with classes
and have device classes that get extended when needed.  There's a (single)
table somewhere that has a list of commands and subroutines that get run for
the command output of a particular device.  There will probably need to be
another table or a master subroutine for each device that handles things like
what final prompt you look for, device nuances, or any other weird stuff like
filtering HP Procurve output.

Something similar should be done to *login, but as my Expect knowledge is
very limited (I can program my way out of a paper bag at this point, but
not much else), I can't say how to do it.  If there's a way to use common
library code with Expect, you could move a lot of the code into libraries
so that there's only one copy of it - the cloginrc parsing stuff, a generic
login routine that will work for most devices, etc.  Even if we keep the
multiple *login programs, at least there will be only one copy of most of
the code.