Mridul Jain wrote:
> Hey things are cool!!It's just a useful discussion.:-)
All right :)
> > 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?
> I think Markus has explained this pretty well.
Well he said performance is not really an issue, but this
is one thing that linux people have been bashing hurd with.
Performance has always been a primary design objective in OS
> > For instance, do you really need to write hurd
> > servers in different languages?
> I am sure that people would like to code in various
> languages.I like c,c++ but think Lisp is great and
> would like to work on it in future.May be others will
> like their favourite and comfortable language too.That
> attracts a varity of programmers and contributors.
That's true. LISP is a good thing. A symbolic language
is much better for certain tasks. Say, you may want to
hook up an NLP code in LISP for a console.
But wait a minute. My god, you intend to turn emacs to
really an operating system now. That's scary. ;)
> > 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.
> Do you think they even provide anything as close to
> HURD servers etc in the user-mode??I think that HURD
> servers running in the user-space itself is a great
> opportunity for programmers.
You know, both solaris kernel and win2k kernel are pretty
modular. In fact, the win2k kernel _is_ a microkernel
design so you could say that it's really similar to HURD.
Remember the subsystems on the win nt microkernel. There
are two APIs implemented one is the WIN32 the other POSIX
(but the one without sockets, you know that). Anyway, those
people have been there'n' done that, and AFAIK they aren't trying to
facilitate a multi-language development for their modular
kernels, why not? Two answers: one they don't want to make
their kernels very open (that's an obvious one) which eliminates
all the aims of using a microkernel. The second answer
would probably be performance and stability.
In fact, the trend seems to me to be even stronger
cohesion between PL and OS. Take Inferno for instance.
Yep, I gotta read that. Couldn't load it last time I checked.
> What I see in Corba is the power to provide
> flexibility whether for different languages or
> protocols etc which is a big boon to programmers.
Hmm. I've been writing the documentation of my dicom 3.0
implementation (comp.protocols.dicom) and I said something like
the following: Interoperability has a cost.
Granted that, what you should try to see is whether interoperability
by means of CORBA has a sufficiently small cost. That cost
comes in various facets: performance, reliability, development.
A major hindrance in any of these would make the revision
In my opinion, you have persuasive arguments that the
implementation can have good performance. I'm not well
persuaded by them though, because I try to reckon the distributed
case which I believe might not be very good with CORBA.
On the other hand, reliability and development costs may be
more serious, especially the development cost.
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara