Re: ORB issues, memory usage, etc.

[Aadi Deshpande <aadi bigfoot com>]

i agree with a lot of points in this matter.  MICO is the slowest, agreed. 
But wouldn't creating an orb from scratch be a lot of work and also
counterintuitive of the philosophy open-source software. 

Instead of rewriting from scratch, wouldn't it be a good option to add the
speed increases to MICO itself. 

MICO is feature-complete, multi-platform, and very well designed.  The
overall architecture of MICO is good stuff(tm) in my opinion. It seems
that it shouldn't be too hard to add the new stuff for CORBA 3.0,
especially the POA, which is what everyone seems to be gunning for. 

Maybe our choice of ORBS is off?  I mean OmniORB is supposed to be several
orders of magnitudue faster and it's also GPL. Maybe adding to OmniORB by
what we learn from MICO (and making it feature complete -- at least to
the degree we need it) is another alternative?

I'm not a learned master in the ways of CORBA by far.  But ordering up YAO
(yet another ORB) for the purpose of using C seems like overkill.

Just Thinkin'

aadi
aadi@bigfoot.com

On Tue, 3 Mar 1998, Elliot Lee wrote:

> Currently we're using Mico (and some related hacks) to provide an
> environment that developers. However, Mico uses C++ and is bloated even
> for a C++ system, so it's not an option for providing an end-user
> environment.
> 
> The GIMP people will also be needing an ORB to replace PDB soon (i.e. 
> after 1.0 settles down)  and tell me they do not wish to require C++ for
> the Gimp. 
> 
> [This is not new for those of you on gnome-components-list - I'm just
> submitting it for a wider audience] So, basically I think we need to write
> an ORB from scratch.
> 
> It will be in C, put performance at the top of the list (methinks there's
> a way to cut the overhead to using a function call variable, for shared
> object activation), and implement CORBA language bindings for C at first,
> other languages later on, plus all the features we need (DII/DSI, POA,
> etc.). 
> 
> I've set up a mailing list - e-mail orbit-list-request@cuc.edu with a
> subject of 'subscribe'. If you are not willing to contribute in the form
> of code or major documentation, please don't subscribe - instead, I'll be
> happy to hear your thoughts via personal E-mail. 
> 
> [Under duress of a class, I'm writing a paper on the bureaucratic ORB
>  issues of ORBit, so if anyone is wanting the low-down on why this new
>  ORB has to be done, I'll be happy to have you all act as proof-readers
>  shortly :-]
> 
> Also, if you see inefficencies in other areas of Gnome (i.e. memory waste,
> reimplementation of the routines already in the shared libraries, etc.) 
> please provide a patch so we can fix it right away. Also please try to use
> pre-existing routines and widgets in the shared libraries instead of
> reimplementing them in your own programs - the reason we have so many
> shared libraries used by most apps is to reduce memory and disk space
> usage compared to other "force the app to reinvent the wheel" approaches.
> (The dependencies also allow us to put the latest technology in all the
> apps, easily, but that sounds like it is more of that bureaucratic
> buzzword crap I should be putting in my paper :-) 
> 
> OK, hope this helps, let the coders spring forth, and let Gnome be speedy
> and frugal,
> -- Elliot					http://www.redhat.com/
> "The obvious mathematical breakthrough would be development of an easy way
> to factor large prime numbers." -- Bill Gates from "The Road Ahead," p. 265.
> 
> 
> 
> -- 
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
> 
>