l4-hurd
[Top][All Lists]
Advanced

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

Re: Meaning of IDL


From: Neal H. Walfield
Subject: Re: Meaning of IDL
Date: Wed, 12 Oct 2005 12:47:31 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Thu, 29 Sep 2005 12:41:53 -0400,
Jonathan S. Shapiro wrote:
> 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.

How do you handle the case where a single capability implements
multiple (and potentially unknown) interfaces?  In the Hurd, file
systems implement the fs interface, which provides mechanisms to find
and manage nodes (think manage directories).  If I have a capability
which implements the fs interface, I can invoke dir_lookup(cap, name)
to retrieve a capability to the object named NAME in the context of
CAP.  The returned capability can provide any number of interfaces.
Normally, the io interface (think file operations) is provided but it
doesn't have to be.  It could, for instance be another directory and
provide the fs interface.  Or it bould be entirely different: the
object may only implement the password interface.  Would you say that
the dir_lookup call returns a capability with the "void" interface?
When using such a capability, would you provide provisions to cast to
other interfaces?

Thanks,
Neal




reply via email to

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