[Top][All Lists]

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

Re: MIG->Corba

From: Eray Ozkural (exa)
Subject: Re: MIG->Corba
Date: Thu, 08 Feb 2001 22:15:59 +0200


Igor Khavkine wrote:
> CORBA is only a source level standard. It is not restricted to IIOP
> or any other message passing protocol, the so to say "backend"
> can be changed according to need. For example regular IPC on the same
> machine can be done through the Mach message passing facilities, like
> MIG does now, however the same code that uses CORBA can easily
> be adapted to use IIOP for remote machines by changing the "backend".
> The details depend on the ORB (object request broker).

Please take my comments lightly, they are meant to be humorous to
an extent. [no flames intended]

So, you're saying that a well optimized ORB can be just as good as MIG.
That raises two other questions:
  1) Is CORBA going to be as slow as MIG?
  2) Is MIG slow enough?

What I mean is really: Be pragmatic. Is this new layer of abstraction
worthwhile and will it not introduce any performance penalty or a limitations?

For instance, do you really need to write hurd servers in different languages?
How useful/suitable would a server written in "perl" be? These are the kind
of questions one should consider before writing a big amount of code. Such
effort would require some justification of the benefits before doing so.

Well, you could try to use XML all throughout Hurd to store all configuration
data. But the result would not be totally desirable. :) (Sorry, I couldn't
resist the joke, that reminds me of Mozilla)

Even companies who are so involved with political statements (sun/ms) don't
try to do that (corba or xml) at the kernel level AFAIK.

In fact, I wouldn't do it if it wouldn't make any major improvement over
MIG. Not that I know a great deal about MIG or CORBA. I don't. But I've
written quite a number of parallel programs so I can predict how much bloat
a message passing system can bring. The distributed case is something to
consider of course, because that was what Mach was supposed to accomplish
and without considering it there isn't much benefit in writing a microkernel
in the first place.

Though, I see your point. It's the same thing that the orbit has been
promising. The case of programs running on the same machine and in same
address space will be so well optimized that it will be like making
an ordinary IPC and a procedure call respectively.

But on the other hand, perhaps what you're thinking of accomplishing through
making CORBA available is taking advantage of object oriented development.
In that case maybe writing a great C++ wrapper around existing code
would be good enough? Don't forget that it really doesn't matter for the
machine whether you're using CORBA or MIG as long as you're using Mach
message passing. And if the target for the revision are developers, consider
how easier will it make the life of a HURD developer instead of how buzzword
compliant it will be.


Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo

reply via email to

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