[cap-talk] What sustained interest in capabilities

[David-Sarah Hopwood]

Mitsu Hadeishi wrote:
> On Jan 8, 2009, at 12:55 AM, David-Sarah Hopwood wrote:
>> Maybe, or maybe not. The difficulty of doing so will depend on the
>> initial design. For instance, if the layer incorporates any APIs that
>> depend too much on an existing non-capability OS (even if those APIs
>> are by themselves consistent with capability security), then any such
>> reimplementation is unlikely to happen.
> 
> You often make reference to this idea, in many of your emails on this  
> subject, but as I keep saying this doesn't apply at all to the designs  
> I have been involved with.  This is not to say they don't have other  
> flaws --- in fact, the design Monty and I worked on I would now  
> improve in a number of ways were I to do it over again --- but none of  
> these flaws involve a mixing of capability security and ACLs in the  
> sense you suggest.  In fact, as I've written before, I'm not sure how  
> or why one would need to do this --- it would actually involve doing  
> MORE work to conform the APIs to any aspect of the underlying legacy  
> software that depended on an ACL-based design.

What I said was "APIs that depend too much on an existing non-capability
OS". That is not the same thing as "APIs that depend on ACLs".

For example, E-on-Java makes many tamed Java APIs available to E programs.
Those APIs are not dependent on ACLs or any non-capability approach to
security, but they are very much dependent on Java, and are difficult
to reimplement. So while the E language has several other implementations,
many E programs will not run on those implementations. This portability
problem would not have occurred if more of the E API had been designed
and implemented from scratch.

-- 
David-Sarah Hopwood ⚥