On Wed, 10 May 2000, Martin v. Loewis wrote:
> 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
At least DII looks standard enough to use in advanced clients. I won't
talk about DSI, I know it not so well yet, but I belive it should be the
part of any ORB.
> 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.
Looks correct, but world's changing quickly ;)
> 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.
I think IIOP still can be used as a transport over TCP/IP network communications.
> 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.
Absolutely. This is like my plan. Obviously I wasn't clear from beginning.
> 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.
I don't see right answer now. I prefer some kind of central server (let's say
ORB-server)
which will be responsible for decision about right transport. It'll definetely take
additional time before I start realisation. I still need more knowledge of
server writing and Mach internals and I have to think more about basic
ideas.
But you get my point now. So discussion gets usefull ;)
Regards. Sergey.
