> From what I gathered, KDE is concerned that CORBA is overkill (and too slow) for > user interface components and document embedding. They say that CORBA is best > for distributing objects across a network but that nobody is really going to > want to run a GUI across a network. So, KDE is planning on making a 'local > library' to handle these things without CORBA. <snip> I think ORBit is quite fast. I recall that Elliot has said that it's allmost as fast as a plain shared library, when running it on a local machine... I'm not sure if this is correct, but I know that ORBit is *very* fast, compared to many other ORB's. ( including Micro$oft's DCOM, which isn't CORBA but often is compared to CORBA ) > I _think_ Bonobo uses CORBA and is not quite what the KDE people had in mind. <snip> Yes, bonobo uses CORBA. Bonobo allso has got a shared library. From what I've understood, the shared library is just a way to make it easier to write bonobo applications, and not to make them faster , because it is simply a big wrapper around the CORBA stuff. Gnome was using MICO in the beginning, but they stopped using it because they thought it was too slow (just after I had got it running ;), and created their own ORB with speed in mind. KDE on the other side, are [still] using MICO, so I think this think about "CORBA is to slow" is more of a KDE matter than a Gnome/Bonobo. > As for Loci, I think what KDE says about the shortcomings of CORBA for GUI > components is valid. The approach we want to take is to get the GUI information > transferred quickly and _once_, via an XML description. We wrote about this at > length in the past. If the user needs a low-level component, Loci will point to <snip> Ok, there is a good point here. Anyone can put their own GUI togeather in runtime, whit a little scripting ( or perhaps a lot of scripting :) No bandwidth is wasted just to make things run. But the same approach is possible using CORBA, you are just not bound to run everything locally. // Liss