variables

[Mark S. Miller]

This is sufficiently interesting that I'm taking the liberty of cc'ing the 
e-lang list.


At 09:33 AM 6/2/99 , Norman Hardy wrote:
>If "file:/jabberwocky.txt" evaluates to the file contents ...

[-] It doesn't.  
It evaluates to a java.io.File object, which, from the E point of view, is a 
capability to read and write the file.  This URI expression expands to

	file__uriGetter["/jabberwocky.txt"]

file__uriGetter is a primordial super-powerful capability (or a Magic Power) 
which, undiminished, should only be handed out to fully trusted programs.  
The capability to read and write the jabberwocky file is granted by 
file__uriGetters.

For explanatory-sequence reasons, which I believe to be necessary for E to 
compete, such Magic Powers are in scope for E applications in *.e and 
*.updoc files, but not for E programs in *.emaker files.  The first 
correspond to the kinds of scripting-language application/scripts people are 
used to writing, which execute with the full authority of their user.  This 
allows pure *.e applications, like Echat, to be written and support true 
inter-user mutual suspicion, without needing further explanation.

Let's call the object that a *.emaker file evaluates to a ConfinedMaker.  
This is analogous to a ConfinedMaker, but different in many ways.  The 
evaluation of a *.emaker file to a ConfinedMaker happens in a scope that 
grants no authority. Further, ConfinedMakers are only able to access 
transitively immutable data, or to import and invoke other ConfinedMakers, 
or Java classes restricted to act like ConfinedMakers.  This transitive lack 
of authority is how E does confinement.  A good way to structure an E 
application is to put virtually all the logic in ConfinedMakers, and then 
have the application's *.e program do essentially nothing but derive 
least-authorities from the Magic powers, and use these to endow objects made 
by these ConfinedMaker.

In KeyKOS terminology, *.e files are a per-application big-bang.  Of course, 
in KeyKOS there was only one big bang.  But KeyKOS got to be the operating 
system the users lived inside of.  OTOH, E has to live within the existing 
user's existing OSes.

I think the above separation provides many of the virtues of your installer 
story: When an application arrives, you audit its *.e files.  If they are not 
small and understandable, refuse the install.  If they are, read them to see 
if the diminished authorities it derives and hand out are 
	1) least authorities for accomplishing the application's purpose, and
	2) authorities you are willing to let this application exercise.
If both of these tests are passed, you should be willing to run an 
application obtained from Mallet without needing to read the application's 
*.emaker files.


(Note: The *.emaker scope restriction is currently implemented, but the 
transitive immutability restriction, and the restriction of the E-to-Java 
bindings to the capability-safe subset of Java, are both unimplemented.  
Therefore, E does not yet support mutually suspicious code being run by the 
same user.  But (as employed by Echat) it does currently support mutual 
suspicion between users.  Transitive immutability awaits auditors.  Since 
Dan's already identified the capability-safe subset of Java, restricting the 
E-to-Java binding to this subset looks tedious but not hard.)


>The more subtle question is: "What is printed for file portion that is 
>changed arter the printing begins?".

[?] What do the Java io libraries do?
When you iterate a file object, the current E implementation opens a 
java.io.BufferedReader on the File, and then repeatedly does readLine() 
until its done.  I suspect the most that can be said in a portable fashion 
is something like

"If the file is written while it is being read, the bytes read at any 
position may only be the bytes originally at that position, or the bytes 
written to that position, but it is not determined which one it is."

Not that this source of non-determinism is fine, as the text read from the 
file is incoming I/O, and would be logged for replay.  Also, an 
inward-bit-confined Bob would not normally be given read access to a File or 
any similarly external I/O channel.


	Cheers,
	--MarkM