capabilities

sellout edited this page Apr 13, 2012 · 2 revisions

The overall structure of a running Kilns instance on a machine looks a bit like this:

[localhost [top <all of your Kilns code>]
           [os <stuff for accessing I/O, networking, etc.>]
           <stuff for passing processes between the OS and top>]

Because of this structure, with all non-functional behavior happening in the os kell, messages nested in kells within top need to be passed up the chain to the top level, at which point they're handed to the OS.

The process

[top [a [b {echo "foo"}]]]

will never end up echoing anything, because the containing kells haven’t coöperated with the most deeply nested one. To make this work, you need something like:

[top [a [b {echo "foo"}]
        (trigger* (down {echo ?body}) {echo body})]
     (trigger* (down {echo ?body}) {echo body})]

Where each level coöperates in bringing the message one level closer to the OS. Of course, you probably want to provide many capabilities to your subkells, and writing so many triggers everywhere doesn't scale so well. There are macros to help with that, EG (enable echo read write …).

[top [a [b {echo "foo"}]
        (enable echo)]
     (enable echo)]

This approach is basically identical to a capability model, where at each level, the capabilities provided to processes at a deeper level must be made explicit.

The simple case of enable allows through any message over that channel, but more fine-grained capabilities can be easily created:

;;; Only allow messages shorter than 15 characters to be echoed.
(trigger* (down {echo ?body})
          (new rc
               {length (list body {rc})}
               (trigger {rc ?length} {< (list length 15 {echo body} null)})))

In fact, the requested capability can be replaced with any functionality. For example, tests/test-examples.kiln merely captures the echo message to compare it against the expected result.

The current implementation has some definite shortcomings, such as

  • all subcomponents of a particular component are given the same capabilities and
  • subcomponents can only describe in comments the capabilities they need or want.