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. > 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?) > 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. Anyway, you call something "not a serious standard" which you obviously haven't even read. 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"). 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. 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. 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). 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. -- -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e| -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
