[cap-talk] Modelling capability manipulation

[Rob Meijer]

On Thu, November 20, 2008 23:57, Neal H. Walfield wrote:
> I've gotten the (perhaps incorrect) impression that an
> object-capability system ought to implement exactly one system
> call---ipc / object invocation---and that all other functionality
> ought to be made available by way of this primitive.

Some initial work I've done on an IPC library for C++ I feel touches on this.
The basic 'functor as cap' interface I am trying to implement is to be
build upon something like the folowing abstract class:

namespace functoripc {
  class AbstractFunctor;
  class AbstractFunctor {
     public:
       virtual void operator()(AbstractFunctor &rcap,
                               AbstractFunctor &acap,
                               std::string xml)=0;
       virtual bool operator==(const Functor &other)=0;
       virtual bool operator==(const int nullstub)=0;
  };
}

The concept would be that the Functor can be bound to a unix domain
socket, and that unix domain sockets can be communicated over functors
that are themselves bound to unix domain sockets, thus implementing a
simple primitive form of cap based IPC.

Would such an interface be anything like what you look for as a IPC/object
invocation primitive?

( Some explanation may be usefull. The () operator its first Functor
argument would be the asynchronous alternative to a return value. The
second Functor argument would be a regular cap as argument. The xml
argument would be a serialisation of any further data arguments.

The first operator== would allow a simple eq operation. The second one
would allow testing for functor==0 as C++ does not have null references
the way java does.)

I feel that the function object as cap concept is a very powerfull and
intuitive one. I'm not yet sure however if I'm completely on the right
track with the above implementation of such.


Rob