l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Meaning of IDL


From: Matthieu Lemerre
Subject: Re: Meaning of IDL
Date: Sun, 02 Oct 2005 21:27:49 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

"Jonathan S. Shapiro" <address@hidden> writes:

> Since this is a separate thread, I'm sending a second note with a
> different subject.
>
> We were surprised in CapIDL that the syntactic migration was small
> (aside: some of the OMG people have been talking with us about their
> next generation IDL). We did run into several areas where the two
> designs are solving different problems.
>
> 1. CORBA is designed to describe interfaces on servers, and there is an
> implicit assumption that the protocol has two big steps: (a) find the
> server, (b) speak on an interface.  In a capability system, you already
> have the interface descriptor, so step (a) is unnecessary. It also
> presents a complex set of security issues.
>
> 2. The CORBA model is client/server. The CapIDL model (and the
> capability model more generally) is client/interface. A client may hold
> multiple capabilities implementing distinct interfaces. It may turn out
> that these are all implemented by the same server process, but the
> client will not know this unless the server agrees to disclose it.
>
> This has minimal syntactic impact, but it is a significant conceptual
> deviation from CORBA. I'm curious whether a parallel deviation has
> occurred in HurdLand.
>

As Neal stated in the other thread, we haven't yet an interface
generator for Hurd/L4 (but we used MiG in the Hurd on Mach).

Our model is closer to a client/interface model : in the Hurd on Mach,
we specify a port send right as an argument of an RPC (which
represents a capability), which is bound to a receive right and not a
particular task.

A server can implement several interfaces: for instance a filesystem
implement both the directory interfaces and the file interface.

In the current Hurd on L4, we specify a thread ID (since thread IDs
are global), but this will change as exposing thread IDs give too much
information to the server, and would be replaced with communication
end points mappings.

So I think our model is closer to yours than the CORBA one, and I'd
like to have a look on CapIDL.

Thanks,
Matthieu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]