Slashdot Mirror
KDE 2.0 Technology Overview
Recently, there was an article about a KDE 2.0 Technology overview here on Slashdot. Unfortunately, the article it linked to was missing some details and didn't give some necessary information, which caused a huge number of complaints and misunderstanding in issues like CORBA, DCOP etc. Now mofset has posted an updated Technology Overview with all the explanations about what's going on with KDE 2.0, CORBA, DCOM, KSycoca and other terms. What do you think?
DDE doesn't do applications embedding. That's OLE. DDE is a horse-dung IPC mechanism that sends messages in the message queue to EVERY RUNNING APPLICATION on a Windows boxen.
The expense of ORB calls can be very similar to the cost of initially calling a shared lib, but from then on shared library calls will tend to be much faster than ORB calls. This difference gets exaggerated when a lot of data is passed in the call and/or in the result, because all of it has to go through the transport representation conversion and data transmission.
Now, while I've done a fair amount of IDL/ORB/IIOP stuff in my time, I haven't looked into the KDE code at all. If they did it right, they should have a lightweight IPC API that can use a variety of transports and that will autmatically use the much faster local *nix capabilities on the local machine, and the moderately slower Xlib capabilties between X-displays, and use CORBA for anything more divergent. Point being the app writer should not have to particularly know or care.
CORBA is VERY time expensive, esp. when you're talking about things that have a dramatic influence on the perception of speed, like redrawing windows.
Often the user's feeling of performance is based more on finding the right place to stick the delay than in having the fastest end-to-end time for a process.
Case in point: I once eliminated hundreds of user's complaints about a slow system by slowing it down about 40%. We had a PowerBuilder (ugh!) front end to a client-server application. One of the forms had a pick list that was HUGE, populated by a stored procedure call. That call would often take 3-4 minutes to complete. Users went bananas because they got the good olde Win 3.1 hourglass while the pick list was populated.
I changed the code to pick up one record at a time from the result set and insert it in the pick list rather than make the single "all at once" call. It actually took 2-3 minutes longer to fully populate the pick list, but the users never got the hourglass and could start working the form right away. Zero complaints.
I guess what I'm saying is, KDE is a UI. As such, it has to focus on user issues, not technological issues. I am 100% a technology guy. I'd rather satisfy myself that things are done right than satisfy users. Even so, the KDE folks want people to use their software. That means they have to address user issues first and put architecture second. It seems to me they are doing a danged fine job of balancing these concerns.
Having recently compiled a snapshot of KDE 2.0, I can say with some conviction that it's a Windows killer. The usability is much better, and the optimised build much smoother. Having had to do some testing of Unix apps running under the Windows Reflections X server, I'm suprised at just how poorly NT performs when more than one application is open. (I mean Windows apps like Outlook and Explorer, not the Unix apps).
The loss of Mico as a dependency for KDE 2.0 is also a good thing. Mico is just too large for it to form the basis of a component model, the only place it really shines is truly network transparent CORBA apps.
Chris Wareham
This article sounds a little bit like spin to me. Not trying to start a flamewar, but here we see a bit of the architectural advantage the Gnome folks have. Writing a completely new ORB (ORBit) might have been a bit 'o work, but it's paying off for the Gnome project, while KDE still struggles with MICO.
Every application supports a basic set of IPC operations for communicating to other applications, and it is not reasonable to expect *every* application to link to any ORB.
I'm no expert, but I'm not sure I understand this. If you're already going to have the ORB running, and you've got the libraries in memory, how much of a price do you pay having 100 applications using CORBA vs. 1 application using CORBA and 99 using some other mechanism?
--
Ian Peters
OK. Lots have people have posted messages to the effect of "In a good ORB, the overhead of a method call to an interface is almost the same as the library." First of, there _is_ an overhead, but we can ignore that.
The big problem with CORBA is _bloat_. If you implement all your internal embedded interfaces with CORBA, it leads to really unweildy sizes.
The server for a simple CORBA demonstration (one structure and 1 interface defining 1 method), compiles to ~70K.
The same functionality, if implemented with sockets or shared libraries, will probably take up less than 10K compiled.
This is the kind of overhead you see with CORBA. Putting CORBA into every nook and cranny of your GUI implementation does not make it 3r33t.
There is a time and place for CORBA. It's not for IPC, and it's not for embedded controls. It's best suited for large distributed applications.
The K people have made a very practical decision by choosing shared libraries.
-Laxative