[Fresco-devel] Re: ACE

> Stefan had Prague's code lying around for the most part from earlier
> work he had done.
> You are assuming that Prague was written from scratch.

Well then perhaps other open source people should have used Prague!
That just proves my point from the converse perspective.

> I put quite some efford into looking into other people's work
> to learn and see whether I can use their work as-is.

Good, good.  (I think you could do better with Prague; but OK.)

> But I can see that often people *want* to rewrite things, for example
> because doing it is a great way to learn.

The write-to-learn motivation is fine, but should be openly disclosed.
It says in effect, "we're more interested in learning APIs than
making things happen."  Nothing wrong with that; just disclose it.

> [Take a broad view of components]
> I don't agree that components didn't make life easier.

That wasn't my argument.  My argument was that a specific class of
components (IDL) have not made life easier between multiple
development groups (e.g. ACE and Fresco).

Within a single group, the broader concept of components obviously
helps a lot.

> Calling the people developing KDE a 'single group' is quite an
> understatement. It always takes discipline to agree on a specific
> protocol.

A 'single group' defines the development path in advance.  (So KDE is a
single group.)  Multiple groups do not, and that is where plug & play
IDL components were supposed to help.  Which is why Windows COM offers
QueryInterface().

These components were supposed to enable software engineers to mix &
match pieces from other projects to build new systems, i.e.,
without the original developers knowing in advance all the uses for
the pieces.

> IDL alone doesn't do anything, it's merely a 'meta-protocol' to write
> specifications in. It's the same as with XML. It's not because you use
> XML that magically all your communication problems will be solved.

Wrong, IDL was designed with express purpose of facilitating
combinations of prewritten components into larger systems.  XML was
designed for abstract data storage -- a different purpose altogether.
One cannot dismiss the failure of IDL to meet its purpose by
calling it a meta-protocol having no specific purpose.

> Again, please have a broader view on what 'component architecture'
> means, and 'code reuse'. We use a *lot* of third party libraries,
> from console implementations (GGI, SDL) to 3D renderers (openGL
> is a good example of a reusable protocol, don't you think ?)

This statement proves my point.  You use libraries, not IDL
components, because libraries are what the world offers you, since
no one is out there writing IDL components.  There is a reason for
this situation.

IDLs are little better than link libraries and that was really
my entire point.  IDL Components have not lived up to their
promise.  So I question the usefulness of IDLs.

IDLs give language independence, but that is not my complaint
against them.  My complaint is that they do not improve component
methodology enough to justify the extra overhead.

> Oh, we agree on this. Most of the projects never make it to an even
> slightly advanced stage. But what has that to do with component 
> technologies ?

As I've said before:  IDL has not facilitated the development of
systems from pre-existing components as it promised.  People are
using other component mating techniques -- some older than IDL, some
newer (.NET).

>> If IDL components were as attractive as originally promised, then we
>> should see instead a snowball effect.  ...  I don't see
>> that happening.

> I do, even though it is not an effect specifically involving IDL

Then we agree, since all I'm talking about is IDL.

> And yes, IDL has its pitfalls. The absense of versioning mechanisms
> is certainly one.

This I don't understand.  A major benefit touted for Windows COM was
that it solves the "DLL-hell" versioning problem.

> Why are you against duplicating work. That's unavoidable ! What are
> the alternatives ?

IDL in theory, unless we are happy with duplication because "doing it
is a great way to learn."

> So ACE was at least at the time no option at all. (and in fact, it
> still isn't, as others pointed out)

Right, because IDL doesn't work as promised (or the ACE guys don't know
how to use it very well).

> no, you offered a good example of fear caused by massive
> misunderstanding of what those licenses actually mean. It may be true
> that business is screaming on the sound of *GPL. But that doesn't tell
> anything about the *GPL. It may just mean that we need to educate
> business better about what these licenses really imply.

That's patronizing.  Business managers can read; so can their
programmers.  They know exactly what the GPL, LGPL, and wxWindows
licenses mean.  I have offered specific factual critiques of LGPL.

LGPL folks often raise this false flag when someone identifies
specific problems in LGPL.  "You don't understand it therefore your
specific critiques are invalid so I don't need to address them."

I'd like to ask why the wxWindows project decided to modify LGPL.
They deliberated for one year.  Are they fear-mongering too?

> other people's arguments aside, my argument (and that was already
> mentioned by others as well) is that you would never expect to be able
> to modify proprietary code (MS Windows, to take the most obvious
> example), so why do you expect it from Fresco ?

Plenty of packages modify MS Windows and some firms have purchased
source code to MS Windows.  In general, many commercial libraries come
with source code or offer a higher-cost source code option.  I can't see
something like Fresco ever working on, say, an embedded system without
some source changes -- which then become LGPL and open to all competitors.

I don't 'expect' anything.  As I've already said, you can make the whole
mess GPL, and then no one but free code advocates will participate.

Every author must decide for himself how large and what sort of crowd
he wants to attract to his code base.

> What I find so cynical
> here is that we do offer much more power than proprietary alternatives
> ... and yet you accuse us of being 'business-
> unfriendly'. That just doesn't fit together, though it is unfortunately
> a very common 'argument'.

To repeat,
"Every author must decide for himself how large and what sort of crowd
he wants to attract to his code base."
To repeat,
"I'd like to ask why the wxWindows project decided to modify LGPL.
They deliberated for one year.  Are they fear-mongering too?"

Regards Stephan,

Mark