Subject: Re: smLangTable indexing: why int?

From: Randy Presuhn <[email-masked]>
Date: Tue, 13 Apr 1999 15:06:18 -0700 (PDT)

Hi -

> To: [email-masked] (David Levi)
> Cc: Wes Hardaker <[email-masked]>,
>         Distributed Management Mailing List <[email-masked]>
> Subject: Re: smLangTable indexing: why int?
> References: <[email-masked]>
> From: Wes Hardaker <[email-masked]>
> Date: 13 Apr 1999 13:22:57 -0700
...
> Lets put it this way...  I wanted to create a configurable scripting
> set that allowed administrators to put lines in a configuration file
> that would point to arbitrary scripting languages
> (/usr/local/bin/perl, /usr/local/bin/tcl, /usr/local/bin/emacs even).
> The problem is I wanted to nicely handle the indexing in the table for 
> the user...  I can't do this now (I suppose I could use a hash value
> and hope not to hit any collisions).  I'd have to have the user assign 
> the path and let them suffer if they rename it.

Since this table is read only, it can't be put to this use anyway.
If you need a table to support creation of scripting environments under
management control, you're free to define it in whatever way suits your
needs.  If it turns out to be useful, then we can talk about adding it
to the specification in the future.

> Even for a router or something else that prompts for a more static
> environment, flash roms can get updated to drop an older language and
> adopt a newer better one.  They'd have to internally develop an
> enumerated list that shouldn't have re-used slots.

I don't see why that's true.  The script MIB implementation is free
to assign those index values.  They don't need to be stored in ROMs
or download files or anything else.

> Since this is already possible using a mib though...
> 
> (Actually, I probably would have picked a octet-string name for my
> specific case, but either would be fine).
...

Octet string names have collisions of their own.  Beyond the simple
problem of ensuring uniqueness (solved by object identifiers), what
"/bin/perl" really means depends on the version of software, who's
hacked it, how it was built, and so on.

 -----------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 Any relationship between my opinions and BMC's is coincidental.
 -----------------------------------------------------------------------

---

From: Wes Hardaker <[email-masked]>
Date: 13 Apr 1999 16:49:27 -0700

>>>>> On Tue, 13 Apr 1999 15:06:18 -0700 (PDT), Randy Presuhn <[email-masked]> said:

>> the path and let them suffer if they rename it.

Randy> Since this table is read only, it can't be put to this use
Randy> anyway.

Yes, it can.  The configuration of the agent configures the mib before 
the agent comes on line and serves the results.  Specifically, this is 
how I'm going to do it.

Now, I'd also make the argument (but I've been holding myself back)
that it should be writable as well...  But then you have very OS
specific issues to solve.  On unix, for instance, I'd like to be able
to create a new row, give it the path to the language interpretor, and 
...

I intend to do this in a configuration file instead, since the mib is
read-only.  There is nothing that says just because a mib is read-only 
that the information contained their in needs to be hard coded into the
agent...

Randy> If you need a table to support creation of scripting
Randy> environments under management control, you're free to define it
Randy> in whatever way suits your needs.  If it turns out to be
Randy> useful, then we can talk about adding it to the specification
Randy> in the future.

The problem is that the index to the smLangTable is used as a
reference in other tables, and its problematic to keep track of
scripts written in one language that reference (by the integer index)
a language that is no longer at that slot in the table.

It's like trying to reference an entry in the interfaces table.  You
can't depend on the numeric integer index, as its likely to move on
the next reboot.

>> environment, flash roms can get updated to drop an older language
>> and adopt a newer better one.  They'd have to internally develop an

Randy> I don't see why that's true.  The script MIB implementation is free
Randy> to assign those index values.  They don't need to be stored in ROMs
Randy> or download files or anything else.

I didn't say it wouldn't be possible...  My point is that indexing
with something else would make it easier and different implementations 
wouldn't have to do different things.  (and managers wouldn't have to
do something like make sure that the language interpretor is still the 
proper language for a given script before it performs the set to push
the run button).

>> specific case, but either would be fine).

Randy> Octet string names have collisions of their own.  Beyond the
Randy> simple problem of ensuring uniqueness (solved by object
Randy> identifiers), what "/bin/perl" really means depends on the
Randy> version of software, who's hacked it, how it was built, and so
Randy> on.

Granted.  Thats a language version specific problem, though.  The
nature behind the language is still "perl" though.

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Apr 1999 10:19:10 +0200

>>>>> Wes Hardaker writes:

Wes> The problem is that the index to the smLangTable is used as a
Wes> reference in other tables, and its problematic to keep track of
Wes> scripts written in one language that reference (by the integer
Wes> index) a language that is no longer at that slot in the table.

Wes> It's like trying to reference an entry in the interfaces table.
Wes> You can't depend on the numeric integer index, as its likely to
Wes> move on the next reboot.

Its usually not that hard to keep these references in sync as long as
they are implemented by the same agent or at least by agents that
share central data structures which provide the relevant numbers.

							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)