Talk:Ambient capability
From Erights
I have never heard of this term. Why do we need it? Isn't the term ambient authority sufficient? Can you give some example of things you (the author) consider as an example of ambient capability? Are there some examples of ambient capabilities that are somehow different from ambient authority? Kosik 01:19, 10 July 2009 (CDT)
Ambient authority doesn't apply unless permissions are enforced in denying an operation. The two are barely even related. Ambient authority not sufficient or appropriate as terminology to properly discuss the circumstances surrounding distribution and mobility.
Consider an object that accesses the following:
- a keyboard
- a monitor
- current local time via a clock
- random number generator
- a HTTP cache
- a Domain Name Service
- a timer (10 Hz event)
- hooking into Data Distribution Service (a distributed publish/subscribe)
- local memory allocations (i.e. to allocate values)
These capabilities are ALL ambient, at least initially. But consider:
- The OS is likely to wrap access to the keyboard and monitor into objects. If the above object is mobilized, the keyboard and monitor still refer to the same keyboard and monitor, thus causing messages to cross the network. That's perfectly fine... keyboard and monitor are reasonably unique, so fit well into the object capability system.
- Access to a clock, random number generator is more questionable. object-capability languages can go either way: allow access as new language primitives, in which case the 'current local time' is ambient to programs written in that language. Or wrap these into objects, in which case once object is mobilized it will need to send messages across the network for each request to the current local time.
- access to HTTP cache and Domain Name Service across a network after mobilization is pointless, but also demonstrate that there's no feasible way for object-capability languages to possibly provide all the desired ambient capabilities AS object capabilities after a mobilization.
- Access to the 10 Hz event and DDS adds an extra challenges: having subscribed to these locally requires handing object-capabilities to other objects on the local system in order to subscribe and later unsubscribe. When mobilizing, however, having a 10 Hz event or DDS updates cross the network is problematic: those services can easily be provided locally for much higher performance, reliability, quality of service. This suggests some first-class support for subscriptions (and later unsubscribe) to ambients is necessary to deal with certain distribution issues.
- Most object-capability languages simply make allocations from local memory into 'primitives' making them ambient to the program, but there is always talk of wrapping memory resources into capabilities in order to handle quotas and such. After a mobilization, the 'primitives' approach means that the object will allocate any new objects on the remote machine, whereas if memory is wrapped into quota caps then one will be allocating memory on its original host. This suggests, at the very least, that quotas need to be handled differently if object-capabilities are to be networked.
Object-capability languages + distribution or mobility benefits considerably from first-class support for ambient capabilities. But to discuss such possibilities requires that one first understand terminology such as ambient capability.
Usefully, ambient capabilities - even 10 Hz events and DDS and HTTP cache and DNS - can be reified. But one needs to explicitly recognize such ambient capabilities as being distinct from object capabilities.
