> As I understand ORBit is going to have DII, DSI in near feature.
> And I think that DII and DSI supposed to be in ORB. Correct me
> if I'm wrong.
No, you are right. DII and DSI and part of the standard. They are just
not very useful, except for very specialized applications. Instead of
the DII and the DSI, those applications could use an internal API of
the ORB as well - for example, people often use ILU's internal API
instead of the DII and DSI. This is only a problem if you expect your
application to run on more than one ORB. But having a C DII and C DSI
in ORBit is no advantage, because you *still* could not run an
application on another ORB - there is no other C ORB with a C DII and
C DSI.
> If you saw my first letter I wrote about use IDL instead of
> MiG defs with help Flick. This directly has to do with Hurd.
Yes, but then considering ORBit, or Mico, or any other existing CORBA
implementation has not much value. As you say, you'd want to use Mach
IPC as a transport instead of GIOP. All existing ORBs more or less
assume that the transport will be GIOP.
What you'd really need is an IDL parser and a stub generator for Mach
IPC. Here, Flick seems to be a good starting point. In the distributed
case, you'd probably want to have an IIOP engine as well. You could
use the one of ORBit, or write a new one - in any case, the CDR/GIOP
stubs should probably be generated by the same IDL compiler that also
generates the Mach IPC stubs.
I'm not sure where the GIOP engine would live on the Hurd. One
approach would be to have a single server per interface (or IDL
module) that provides remote proxy objects. Applications would then
treat local and remote objects the same way, using Mach IPC. Inside
the server, CDR marshalling and transmission over TCP would happen.
The alternative is the traditional CORBA implementation strategy: Each
client manages all TCP connections itself, and therefore contains
stubs that operate either over Mach IPC, or TCP.
Regards,
Martin
