On Sun, Feb 25, 2001 at 11:12:28PM +0100, Ernst Lippe <[EMAIL PROTECTED]> wrote:
> No, but i believe that distribution is a nice thing to have, e.g. to be

That's exactly why I mentioned MCOP. You still didn't read the
documentation? It is very easy to find out that MCOP ist just as
distributed as CORBA.  Except maybe faster.

> 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.

If the target audience is free software than CORBA doesn't scale good
here. Also, a standard becomes standard by getting accepted by the "target
audience" (which I'd like to call the community here), something that
isn't helped here by acceptance by companies (compare this to the java

> * 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

Actually, it scaled very bad here, as you say so yourself:

> no really good open source implementations at the moment (there are good

target audience *is* open source.

> How do DCOP and MCOP score on these criteria?

MCOP doesn't scale particularly wel, but it's similar cousin, DCOP, does
score quite good, don't you think? Good documentation, widely and actively
in use, good implementation that has proven to be stable.

> > 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?

I don't know. Most probably for performance reasons.

> I have read them

You must have slipped almost all the sections, though...

> them as standard documents. As I said above, writing a good standard
> document is really hard work.

Certainly. HTML took at least 5 _major_ iterations so far and was never
actually implemented anywhere.

> > 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. 

Read what I wrote. Then use tcpdump to very actually _measure_ the size of a
CORB_A packet. Of cours there i a size of a CORBA packet, how would the
kernel know to transfer it if there were no size attached? ;)

No kidding, I wrote "reality", not "CORBA could". You answered "it depends
on the implementation". Sure, commercial implementations might be better,

> My argument is simply that CORBA is a good standard.

I don't think this was nearly clear. I also agree to this. But XML is
also a good standard. Should we therefore use XML to transfer image
data? The quality of a stanard means nothing for its applicability to some
problem. In fact, many people think it does: Part of the problem.

> I looked at the MCOP documentation. I have been using CORBA in some real
> world applications and it works.

Sure it works. DCOP works. MCOP probably also works.

> 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.

I am indeed mixing two problems: applicabilty of some protocol for
some problem AND social consequences of some standard. Both of these
contribute to my argument, though, which is: don't accept everything:
think thoroughly first.

> The fact that some standard was written by a large organization does not
> necessarily mean that it is a bad standard.

In fact it means nothing.

      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       [EMAIL PROTECTED]      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
Gimp-developer mailing list

Reply via email to