Subject: Re: Tentative disman slot

From: Eamonn McManus <[email-masked]>
Date: Mon, 31 May 1999 19:04:28 +0200

Juergen Schoenwaelder <[email-masked]> writes:
> Randy> Please post any topics you'd like me to include in the agenda.
[...]
> We also need time to discuss issues related to RFC 2592 which have
> been raised on this list. So far I have:
> o Restartable scripts

I'm not sure what this means.  Did you mean scripts that are run
automatically on device startup?  If not, that needs to be added to
the list.

> o Error message during script compilation (smScriptError)

I'd just nitpick a little and say that the error message is broader
than just compilation.  The example I mentioned is if a script is
digitally signed and the signature verification fails.  That's not
covered very well by the existing error codes but it's not necessarily
practical to add new error codes for every new eventuality like this
that comes up.  Having an error string as well is more flexible, if
not very easy for automated managers to exploit.

> o Scripts that can run forever without having to reset smRunLifeTime

I'd like to retract an incorrect correction I posted earlier: the
maximum value of smRunLifeTime and smRunExpireTime is indeed
2147483647 and not 4294967295 as I said.  For some reason I thought
the type was TimeTicks rather than TimeInterval.

> o Index smLangTable and smScriptTable by name rather than Integer32

Isn't it just smLangTable that needs to be so indexed?  smScriptTable
is already indexed by owner and name strings, though it currently
contains a column that is a numeric index into smLangTable.

For what it's worth, I haven't found the current numeric index values
to be particularly problematic.  They just mean my manager (client)
has to scan the smLangTable when it first connects to a device, in
order to find the entry for Java.  That isn't particularly burdensome,
and the alternatives suggested, insofar as I understand them, don't
seem any simpler.

A couple of additional areas that might be of interest:

- Dependencies between scripts.  If Script A requires Script B in
  order to function there might be some indication of this in the MIB.
  I'm not saying this is necessarily a good idea, though.  Probably it
  is better for the dependency information to be stored in the scripts
  themselves and for the manager to extract and record it.  This does
  mean that the manager has to look inside scripts, which is not
  currently the case: now the manager doesn't have to access them at
  all because it just hands a URL to the device being managed.

- Script versioning.  Perhaps there should be an object in the
  smScriptTable that associates a version number with a script.  Of
  interest too is the question of whether the Script MIB could help in
  the task of upgrading a script to a newer version.  Currently the
  only support for that is the unappealing smCodeTable.

We don't currently support either of the above and were thinking of
implementing them by stashing the information of interest in the
smScriptDescr object.

,
Eamonn
--
The Open Group Research Institute, 2 ave de Vignate, 38610 Gieres, France.
Phone +33 476.63.48.82.  Fax +33 476.51.05.32.  http://www.gr.osf.org/~emcmanus