[cap-talk] A Taxonomy of Current Object-Cap Systems

Matej Kosik kosik at fiit.stuba.sk
Wed Mar 4 07:48:30 EST 2009

Toby Murray wrote:
> Hi all,
> (apologies for cross-posting)
> I'm trying to put together a taxonomy of current object-capability
> systems. I'm hoping people can help fill in some of the many missing
> items in my list so far.
> The only criteria for inclusion is that there must be a working /
> prototype implementation for the system in existence right now -- i.e.
> it must be possible (even if very difficult) for /someone/ to write code
> for this system today. Notable omissions therefore include KeyKOS and
> (D)CCS (the first object-capability OSes) and Gedanken (the first
> object-capability language). 
> The list omits caps-as-data systems in which objects can handle the bits
> of a cap-as-data directly, such as the E sturdyref part and Webkeys.
> Partitioned password-capability systems (like Annex) are, however,
> included.
> The current systems included in the taxonomy are:
> E
> Cajita (and other JavaScript subsets)
> Joe-E
> Emily
> CaPerl
> Sahara
> Coyotos
> seL4
> OKL4
> Annex (2008-09)
> If a systems is missing above that you think should be included, please
> let me know.
> If you know something about one of these systems, please read on.
> The current features of the taxonomy are the following:
> OS / Language - whether the system is an operating system or programming
> language. e.g. EROS is an OS. E is a language.
> Single-Threaded - whether objects in the system all share a single
> thread of control e.g. E and EROS do not. Joe-E does.
> Inter-Thread Sync. Sends - whether the system allows objects running in
> different threads of control to send messages to each other
> synchronously, e.g. E does not, EROS does. This is not applicable for
> Single-Threaded systems.
> Recursive Reentrancy - whether the system automatically allows objects
> to be recursively invoked, e.g. E does. EROS does not.
> Async. Comms. - whether the system allows asynchronous communication
> between objects. If so, whether it allows async. sends, receives or
> both. e.g. E allows both async. sends (<-) and receives (when (p) ->
> {...}), Joe-E allows niether.
> EQ - whether the system provides an EQ implementation (even if it is not
> universally available to all objects), e.g. EROS/CapROS do (via
> Discrim), as do most languages (via '==').
> If you think there are distinctive features any current systems that
> should be included in the list above, please let me know. My main
> criterion for inclusion here is that a feature must affect the way
> object-capability programmers might program in the system and the sorts
> of things that can be expressed in the system. 
> My current draft incomplete taxonomy is here (PDF -- if there's demand,
> I'll transcribe this to the erights wiki once it converges):
> http://web.comlab.ox.ac.uk/people/toby.murray/tmp/taxonomy.pdf
> Please consider having a look at it and replying with details to help
> fill in the missing bits or to correct anything I've got wrong. I think
> a current breakdown of different kinds of object-capability systems
> would be very useful to have. 
> Full Disclosure: I intend to include this in my PhD thesis, which is the
> primary catalyst for assembling it. I will happily give credit to all
> contributions via a footnote at the point at which the table is included
> in the thesis, as well as a mention in the Acknowledgments section. 
> Cheers
> Toby

Very short description of relationship among Pict, Tamed Pict, Sahara
can be found here:
Relevant text starts at page 4. The paragraph above the figure.

Pict is finished.
Tamed Pict is finished.
Sahara is finished.

but these are intermediate stages toward a language that not only
supports creation of *defensively consistent* components but
also *defensively correct* components.
(while avoiding reliance on the OS kernel).

More information about the cap-talk mailing list