Hi all,

With Stan's permission I am forwarding his comments to the list.

Jeff Vance, CSY

--- Forwarded mail from Stan Sieler <[log in to unmask]>

From: Stan Sieler <[log in to unmask]>
Subject: Re: (Fwd) Design for System CI vars (long)
To: [log in to unmask]
Date: Thu, 26 Sep 1996 10:29:33 -0700 (PDT)


I don't think you want to waste the effort designing a fancy security
mechanism for system variables.  At best, how about having a couple
of bits for variables:

  readonly     ... is a 3 bit field, internally.  if 0, is not readonly.
                   non-0 records if the user who said "make it readonly"
                   is SM (3) or AM (2) or simple user (1).
                   A value of 4 would mean: the SYSTEM says this is readonly,
                   thou shalt never override it (today's readonly vars)

                   The permission hierarchy should be evident.

  writeonly    ... ditto
                   (Yes, one can conjecture a need for a variable that
                    can't be read, and can only be changed ... particularly
                   if variables are linked to procedures)

WAIT...those are exactly backward names...if one has two concepts like that,
it should bne "readable" and "writable", not "readonly" and "writeonly".
The readable/writable corresponds to file system security ...
the readonly/writeonly are (a) made up words; and (b) INTERPRETATIONS
of readable/writable.

Anyway, a minimal security system (above), coupled with a simple
inheritance mechanism (with the default being HISTORIC inheritance,
where a local var in a script is seen by nested scripts) would be the
most useful.    (Remember, with the historic-scope (as opposed to static
scope), you cannot achieve one of the original goals: temporarily
redefing the value of a variable.)

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html

--