capability types

[Neal H. Walfield]

At Wed, 12 Oct 2005 14:10:34 -0400,
Jonathan S. Shapiro wrote:
> 2. A capability *names* precisely one interface, by
>    definition. This interface *may* (but need not) include
>    operations that return other capabilities. These other
>    capabilities may or may not name the same representation
>    state as the original capability.
> 
>    Examples:
> 
>      The Void capability does not have any methods that
>      return capabilities.
> 
>      The EROS read-write page capability has an operation
>      that returns a read-only capability to the same page.
> 
>      An EROS space bank capability has an operation that
>      returns page capabilities. These capabilities
>      do not name the space bank.

I think I understand your examples but I am not convinced that: we can
statically determine what interface a capability names based strictly
on the RPC name; nor that a capability necessarily names precisely one
interface.

In the Hurd, most objects are made accessible via the virtual file
system.  When a task wants to create a pipe, for instance, the
standard Hurdish idiom is to ask the pflocal server.  To find the
pflocal server, a task obtains a capability to `/servers/socket'
(which presumably names the fs, i.e. directory, interface).  The task
invokes that interface using the dir_open method with the string
argument "1".  (Why 1?  That is the number associated with PF_LOCAL.)
The returned capability presumably names the socket (server)
interface.  The reason that we know this is not because dir_lookup
necessarily returns capabilities which name the socket interface but
because by convention, the node /server/socket/1 names an object which
can create sockets.

Using the capability, I can invoke the socket_create method.  The
pfinet server will typically return a capability which names the
socket (client) interface AND the io interface.  Using the socket
(client) interface, a task, for example, can connect two sockets to
create a socket pair.  Using the io interface, a task can read from
and write to a socket.

How would capidl express these two usage modes?  Would you recommend a
different model?

Thanks,
Neal