[E-Lang] Announcing E 0.8.10alpha1: Distributed again, Persistent (sort of), and Confining

[Mark S. Miller]

 From the first part (of three) of "Highlights of this Version" 
http://www.erights.org/download/0-8-10alpha/index.html#Highlights .  
Follow this link to see the text with all the embedded links.  I'm sending 
the text redundantly in email in order to facilitate discussion.  On the web 
page, each "Track this issue..." below is actually a link into our new bug 
tracking system!


As each of these issues are discussed in email or in the bug tracking 
system, we will link the paragraphs below to the relevant roots.

E 0.8.10alpha1 is the first version of E to simultaneously be 

* Distributed (hence no "sl-" prefix, as explained below). This version 
  implements the 2vat subset of the much improved CapTP protocol that's been 
  on the drawing board for so long. Chief among the CapTP improvements: We now 
  have full message pipelining. Since we've postponed making the 3vat 
  introduction cases work, we have instead made them fail clean, and verified 
  that they do so. 
  ( Track this issue... )

  This version also incorporates Bill Frantz's improvements to VatTP, merged 
  from the branch release 0.8.9.1b. Between the new VatTP and the new CapTP, 
  we are more confident than ever in our distributed security. (And so this is 
  an "E" rather than a "daffE", as explained below.) 
  ( Track this issue... )

* Persistent (hence no "tl-" prefix). The version has an early, experimental 
  preliminary form of support for identity persistence. With identity 
  persistence, the application still has to do all the "manual" work to save 
  an restore object state, but the app can now securely reassociate old 
  persistent identities (as designated by exported SturdyRefs and <cap:...> 
  URI strings) with the manually revived objects. To aid in this manual work, 
  E programs can use the new Serializer and Unserializer, which default to 
  rules suitable for checkpointing and reviving persistent object state. Not 
  yet ready for prime time. 
  ( Track this issue... )

* Confining (hence no "otc-" prefix). As with 0.8.9t and 0.8.9t.1a, 
  *.emakers are imported with no real authority to affect the world outside 
  themselves. All authority must be granted, and so can be granted according 
  to POLA. Nothing new here, but we've never had this in a distributed version 
  of E before.
  ( see Mark Seaborn's thoughts on a module system for E )

  This issue appears again at a higher layer: Marc Stiegler is preparing an 
  all out assault on the caplet environment -- gui support for interactive 
  POLA authorization of untrusted applications (themselves represented as 
  emakers).
  ( Track this issue... ) 


        Cheers,
        --MarkM