[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RE: cuteidl -- maybe we should give a thought to OmniORB
From:       Lotzi Boloni <boloni () cs ! purdue ! edu>
Date:       1999-09-21 21:09:05
[Download RAW message or body]

On Tue, 21 Sep 1999, David Faure wrote:

> On Tue, Sep 21, 1999 at 03:38:37PM -0500, Lotzi Boloni wrote:
> > > Well, this OTOH would kill cuteidl.
> > 
> >   No, why? I am speaking about the ORB, not about the IDL. I know that
> > they are interdependent but unless I have a very bad understanding of what
> > is going on, cuteIDL is a new mapping, essentially idl2qt or idl2kde
> > instead of idl2c++. And it uses MICO as ORB. 
> 
> It's rather IDL to (Qt/C++)  instead of  IDL to (CORBA::* types)
> 
> >   So you can reuse most of the code and use the other ORB instead, because
> > the mashalling code should be the same (if I am not an absolute idiot).
> 
> I'm not sure about that part at all. The marshalling code is really
> dependent on the ORB's implementation. Oh sure, it's probably possible
> to do it with any ORB (provided that it's as modular as MICO is), but
> that's even more work, it's not something obvious.
> And we're only making assumptions here, whereas we already have something
> working well if we keep MICO (and keep improving it).
> And as it seems we can turn our ORB into whatever we want it to be,
> why switch to another one ? We would have to turn that other one into
> what we want it to be, so we gain nothing by switching. (headaches perhaps ?).

  Well, some headaches are inevitable. Still, just a thought experiment:
assume that I will port kded to OmniORB. What are the objective
measurements, like speed, memory etc which would make it worthwhile the
switch? 

            Lotzi

[prev in list] [next in list] [prev in thread] [next in thread]