Marc Lehmann wrote: > > On Sat, Feb 24, 2001 at 01:58:06AM +0100, Ernst Lippe <ernstl@xxxxxxxxx> wrote: > > protocol for communication between plug-ins and Gimp that are all > > running on the same machine, you are free to choose any non standard > > protocol you like. > > It's free software. You are always free to use whatever you like. Nobody > can force you to use some specific protocol for _network_ connections > because it exists. No, but i believe that distribution is a nice thing to have, e.g. to be able to communicate with scanners/printers that are not attached to your local machine or to be able to communicate with some 3D rendering application that is running on a powerful server somewhere. So I am very much in favor of a protocol that can handle network connections. > > Other protocols like KDE's DCOP or MCOP as you mentioned are not serious > > standards. > > Well, naming something "not a serious standard" is not a serious statement > ;) (Why?) Too few arguments perhaps? All right, what properties should a "good" standard have: * It must be unambiguous and clear. This is hard work that usually takes several iterations to get right. * It must be accepted by a large part of the target audience. * There must be good technical support for it in the form of tools and applications and additional documentation (tutorials etc.). CORBA scores good on these points. Its only drawback is that there are no really good open source implementations at the moment (there are good commercial ones), but I am certain that they will come. How do DCOP and MCOP score on these criteria? > > Using shared memory is only useful when the two processes are running on > > the same machine and you could still define a CORBA interface to set it > > So if we want to open Gimp for a distributed environment > > This is true. But so far everybody who tried it seemed to have given up. Why? Because of some inherent shortcomings in CORBA or in the implementations that they have used? > Anyway, you call something "not a serious standard" which you obviously > haven't even read. I have read them, and I am afraid that I was not very impressed with them as standard documents. As I said above, writing a good standard document is really hard work. > I was talking about MCOP, not shared memory. Yes, > MCOP is extremely fast with shared memory. It also also quite fast with > TCP (compare the average size of a corba packet with the mcop case for > example. And I am talking reality here, not "but in theory CORBA could"). There is no such thing as the size of a corba packet, it is highly dependent on the implementation you're using and the situation. > The only pre-existing argument in favour of CORBA is, in fact, that gnome > uses it and to be very compatible with gnome you must base your software > on corba. This argument might be a very important one (e.g. KDE doesn't > use CORBA ;) since there are strong historical ties between gnome and > gimp (the mother of it all). It does not mean that not thinking about > alternatives is verboten. My argument is simply that CORBA is a good standard. > In fact, calling MCOP "not serious" without having looked at it just shows > that most people do not even *think* about possible alternatives but just > run blindly into some direction. I looked at the MCOP documentation. I have been using CORBA in some real world applications and it works. > Remember that I am not advocating MCOP here, but rather thinking > critically about CORBA, it's usefulness and it's application. Just because > CORBA was done by OMG *must* not mean to use it blindly. Otherwise we > could just as well also follow windows instead of trying to innovate (the > gimp menus, for one thing, are definitely non-standard. I would love them > to become standard. But as they are, they are not a "serious standard" > because neither a standards agency advocates them nor are they widely > used). > > For example, what has CORBA done to gnome so far? All I see is a > bewildering multitude of apis that most people don't understand. Gnome > really *has* become a mega-API with functions for each and everything and > then some. In practise this leads to hard-to-factor components because > nobody understands the dependencies anymore. A famous example of this is > the annoying stubbornness of many gnome applications to start a whole > bunch of other processes (the gnome-panel for example), without being > asked for. This leads to strange effects sometimes: > > On my neighbours display (often an IRIX machine) I can see the 4Dwm > environment together with - for him - a quite useless gnome-panel > and other gimmicks he cannot turn off except by closing everything > (including his app). All that because he just started gnome-icu (or > some other app). > > This has nothing to do with the beatifulness of a nice kernel/userspace > abstraction with clearly defined interfaces (unix). (See for example > Miguels article http://www.helixcode.com/~miguel/bongo-bong.html, which > sounds like a lot of good arguments to make user/system communication more > colourful and less efficient). Please make a distinction here between CORBA and the interfaces that people describe in CORBA. It is just like the difference between writing in a good programming language and writing a good program. > What I am asking for is critical thinking (or at least active > thinking). Not turning down something else because it isn't spelt > C-O-R-B-A and no other reason. When I started working with CORBA is was pretty critical myself. But the stuff is actually working and I like it. The fact that some standard was written by a large organization does not necessarily mean that it is a bad standard. Greetings, Ernst
