26 Nov 2002 pphaneuf   » (Journeyer)

jbucata: Interesting parallel that you pointed out.

I'm actually on the side of the people who think that X Window isn't doing so bad, except maybe that there should have been (or be!) more effort into optimizing the (now common) case of local connections. You have the correct parallel, but you are positioning XPLC incorrectly.

Say that we complete the picture a bit more by adding the Windows GDI and Fresco (formely known as Berlin). In the former, everything is local and there is no remoting possible, and in the latter, everything is accessed through CORBA. You could say that things like the Apache modules are like the Windows GDI, all specific, hardcoded and hardly remotable, and Fresco is like, well, CORBA. The thing is, both are right in what features are needed, but the compromise (or lack thereof) that they made is what is actually questionable.

Enter the X Window System. Instead of using a generic and transparent remoting system like Sun RPC, they designed a precise and rather simple interfaces embodied as an (relatively) efficient protocol. People may find this discutable, but between re-implementing the Win32 or an X server from scratch, I'd rather take the X server (case in point, WINE is struggling after all these years, while we have seen X servers come and go many times in the same period of time).

Note how C doesn't allow for remote procedure calls, but Xlib manages to have them anyway in an efficient way, without too awful of an API (compare with COM/DCOM's HRESULTs, for example). CORBA makes better APIs, but at the cost of layers upon layers of management code, which adds up for awful lot of overhead. XPLC is a bit like C and C++, it has components, doesn't have transparent remoting, but remoting can be done too, perharps even in a nicer, more robust and more efficient way. It just won't be transparent, maybe only translucent, but that should be good enough. XPLC itself won't have anything in it related to remoting, but I intend on having a framework to support remoting available separately (a bit like DCOM is built over COM).

Also, CORBA may be nice, but it deals mainly with objects, and rather heavyweight objects at that. While component systems in the past have managed to get good results without making most objects a component, the ideal component world would be to have everything be a user-replaceable component (I understand that this is rather extreme, but bear with me, this is just something we should aim for). The fact is, you could take many normal C++ applications and 99% of the classes into XPLC components without too significant overhead. You probably don't want to do that in such a non-discerning manner, but you wouldn't die from it. On the other hand, doing the same thing with CORBA, you'll probably die of hunger waiting for your application to do anything at all.

The whole point is that being easy to use, low speed and memory overhead, language and platform neutral should leave no excuse for applications not to be and/or use components.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!