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

List:       kde-core-devel
Subject:    FW: [Fwd: Re:A new framework for embedding]
From:       David Faure <David.Faure () CRAMER ! CO ! UK>
Date:       1999-09-29 12:37:08
[Download RAW message or body]

Some good points from outside kde-core-devel, which I've been asked
to forward (I forgot about the archives !)        :)

From Julian Adams <julian.adams@gmx.net> :
> > Hi all -
> > 
> > I use KDE on my LINUX box, and it's a great GUI. I also lurk on a few
> > lists (the WM_SPEC list, KDE-CORE-DEVEL, KDEV, slashdot,
developer.gnome.org). 
> > This is just my comments - I hope they're not too long / boring.
> > 
> > As a developer I get paid to do MS + DCOM and (just recently) CORBA.
> > DCOM has strong
> > 
> > parallels to CORBA. Having used it it''s clear that components are the
> > future as they enable
> > 
> > scripting of just about anything in a generic, cross language, network
> > transparent manner.
> > 
> > Working on large projects components not only enforce layers of
> > abstraction, they also mean
> > that you just use pre-existing components. But you know all that.
> > 
> > (IMHO) Miguel Gnome is right when he says that multiple language
> > bindings will be essential
> > 
> > for the component future. He's plainly wrong when he often claims that
> > you KDE guys are "only" C++. 
> >
> > The Python bindings for KDE are as good as any for GNOME and
> > you have other languages too.
> > 
> > Now CORBA is the tool which will enable multiple language binding /
> > scripting of anything
> > 
> > due to a component desktop architecture. It's the glue that 
> > will stop everyone having to
> > 
> > write new binding by hand, that cause gnome to do 
> > everything in plain standard C.
> > 
> > It seems that there are 3 set of views on CORBA:
> > 
> > 1) Those who love it.
> > 2) Those who think it has great value, but performance issues.
> > 3) Those who don't think that it has great value.
> > 
> > On 1) I've seen people say great it's an interface we'll 
> > make it CORBA. Rubbish. E.g. the
> > window manager spec. There's already an implemented IPC 
> > mechanism for X. Who needs to bring
> > in CORBA complexity? Use it if you need it.
> > 
> > On 2) It's going to allow everything to be scriptable / accessible.
> > 
> > On 3) Either people can see the value of the interoperability. I'm not
> > going to argue with this. Time will tell. Or the performance issues 
> > may be currently too great.
> > 
> > Now I'm in 2). :)
> > 
> > THE POINT OF ALL THIS:
> > 
> > If CORBA is too slow / unstable ditch it. But remember what you are
> > loosing.
> > 
> > Remember too that CORBA is not inherently slow AT ALL. But the
> > implementation may be very
> > 
> > slow. A CORBA implementation which loads shared libs can be 
> > as fast as a manually loaded lib
> > 
> > - once the initial binding is done.
> > 
> > Shared libs are faster than IPC, but they are (potentially) 
> > much more stable. Much of MS's
> > 
> > instability comes from loading components into the same 
> > address space, with massive
> > 
> > multithreading. Separate applications with IPC (e.g. CORBA) 
> > bridges can be much more stable.
> > 
> > In KOffice's case this does not seem to be the case. Is that a MICO
> > issue ?
> > 
> > So why not use CORBA and make it fast. Surely this is the way to an
> > interoperable future.
> > 
> > Julian


--
David Faure
faure@kde.org - KDE developer
david@mandrakesoft.com - Mandrake
david.faure@cramer.co.uk - Cramer Systems

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