On Sat, Feb 24, 2001 at 01:58:06AM +0100, Ernst Lippe <[EMAIL PROTECTED]> 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      +--
      --==---/ / _ \/ // /\ \/ /       [EMAIL PROTECTED]      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to