Hi All,
 
I also forgot to make my reply to Jeff Kell public:
 
--- Forwarded mail from <[log in to unmask]> ("Jeff Vance")
 
From: "Jeff Vance" <[log in to unmask]>
Date: Thu, 29 Aug 1996 23:19:56 -0700
To: Jeff Kell <[log in to unmask]>
Subject: Re: Design for System CI vars (long)
Cc: [log in to unmask], [log in to unmask]
 
Hi Jeff,
 
On Aug 30, 12:50am, Jeff Kell wrote:
> Subject: Re: Design for System CI vars (long)
> Jeff Vance wrote:
> >> Need for System CI Variables:
> > -----------------------------
> > Why can't MSG files work?  Perceived greater overhead, more complex,
perhaps
> > not transient enough (system variables will disappear on a reboot).  Of
> > course MSG files can hold more data than a CI variable, which is limited
> > to 1024 bytes. (Conventions can be used to "chain" together many system
> > variables.)
>
> I disagree (for my interest).  MSG files imply a one-to-one
> relationship, and while MSG files can do this (and we've done it) my
> interest is a one-to-many pathway of communication (multiple instances
> of an application, multiple applications within a package, or multiple
> packages across the system).
 
OK, thanks.
 
snip...
> Take a "horizontal analysis" and look at Posix environment variables.
> This would solve many of your "scope" concerns (it's local or
> exported).  Posix environments inherit the CI vars of the invoking CI
> (logon shells) and resolution is fairly well defined.
 
Yes the POSIX export model is simple; however a couple of shortcomings come to
mind: 1) a child process cannot change a variable in an ancestor process (all
exported vars are pass-by-value), 2) there are no peer-to-peer shared vars
(that
I am aware of, unless you want to used shmem for this).  I guess I still
don't understand what you mean by "horizontal analysis", sorry.
 
> You seem to be
> taking a "lexical context" approach where you are associating common
> names with different environments (CS term is "overloading") and trying
> to define default behavior.
 
I am trying to let a "more local" variable hide/override a "more global" var of
the same name.  Is this overloading?  I see it as a common programming language
feature.  E.g. in C: external = system; defined before main() = job/sess;
defined in main() = process local; defined within { block = script local (kind
of...). I am not a C expert so I may be missing something in the analogy!
 
> Heck, steal some Perl code and have as many
> variable namespaces as you wish (System=>somevar, Session=>somevar,
> Process=>somevar, Script=>somevar, etc) and even get into messing with
> the variables of external environments (modifying locals in another
> scripts locals).
 
That got me thinking...maybe I need to consider more carefully the mixing
of POSIX vars and CI vars.  Today they are very separate with the shell
inheriting a copy of all CI vars.  But beyond that there is no connection.
E.g. CI vars live in a var tbl object, POSIX vars live in the heap.  A CI
var can have a procedure name as its value, and this procedure is called
when the var is referenced.  POSIX vars are a varname=value list.
 
> But my own opinion, let's not get too complicated.
 
Agreed.
 
> My primary need is
> for the ability to set system variables (like the HP@ variables) so that
> any process on the system can read them.
 
Meaning your primary need is for general IPC?
 
> Your local variables are
> convenient, but by definition they are more of a convenience that a
> defined need.
 
OK.  So system level vars as I defined are important to you.  Do you also
need process local vars that could work like exported POSIX vars?  The
scoping would then be: system(new), job(today's vars), process(new),
[optional: script-local(new)].
 
>
> Be careful about your overloading rules, or you'll get very complicated
> not only in your coding, but also user understanding, consistency, and
> intuitive elegance generally afforded by MPE.
 
I need to better understand this point.  The rule could simply? be: when a var
is referenced first look for a script local var (if in a script), then a
process local var, then a job/sess var and finally a system var.
 
Thanks for your comments,
Jeff
 
--
 
 
---End of forwarded mail from <[log in to unmask]> ("Jeff Vance")
 
--