[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    [e-lang] A Taxonomy of Current Object-Cap Systems
From:       Toby Murray <toby.murray () comlab ! ox ! ac ! uk>
Date:       2009-03-04 11:21:07
Message-ID: 1236165667.17684.42.camel () clpc130 ! comlab ! ox ! ac ! uk
[Download RAW message or body]

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
EROS/CapROS
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
_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang
[prev in list] [next in list] [prev in thread] [next in thread]