Re: [Fresco-devel] Re: ACE

M. Evans wrote:

> It's not a question of forking in response to them, but in spite of
> them.  Components were supposed to marry code from various
> parties to make building software systems easier.  That promise has
> never been fulfilled.  Otherwise we would see open source folks
> cooperating a lot more (on the basis of IDLs).

There are lots of reasons people may consider to reimplement specific
things. I put quite some efford into looking into other people's work
to learn and see whether I can use their work as-is.
But I can see that often people *want* to rewrite things, for example
because doing it is a great way to learn. And more than anywhere else
it is important in FS projects to let people do what they *want*, not
what to outsiders looks most useful. An interesting question is how
to let those two goals converge, but that is a matter of much broader
scope than just programming, or engineering...

I don't agree that components didn't make life easier. Components
are everywhere, whether we call them like that or not. And the protocols
we use to let them communicate are much more manifold than just IDL.
IDL seems to be not very popular, as it requires particular software
to generate language specific APIs, and adapters to implement the
marshalling. As Nathaniel points out, there are quite a number of
pretty successful component based architectures in use in Free
Software and elsewhere. I wouldn't characterize that a failure.

> The examples you cite all involve single groups.  So they do not fit
> this argument.  Code interoperability within a single development
> group hardly needs an IDL.

Calling the people developing KDE a 'single group' is quite an
understatement. It always takes discipline to agree on a specific
protocol. Whether that is expressed in IDL or in different languages.

> The IDL problem is getting code
> from different groups to interoperate.  Note how Fresco, while
> using an IDL, fails to incorporate *any* IDL components from third
> parties. (Correct me if that impression is wrong.)

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. You
still have to define the structure of the content, and notably the 
semantics associated with the API, i.e. how to interpret it.

Specifically, there are currently no projects providing IDL interfaces
for the domain we are working on (graphical environments). There are
general services which we use (name service, trading service), and
there was a proposal for a 'Compount Document Architecture' back in '94.
Coincidentally, there were actually two such proposals, one was
'OpenDoc' (which is now dead, and no free implementation exists, or 
otherwise we would use it), and Fresco itself (then driven by Fujitsu).

We are now looking into the interfaces defined by OpenDoc, to see
whether we could use them. But even then, as there is nobody providing
implementations to them, chances are that we will take whatever pieces
are useful for us, and incorporate them into our own code base.

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

> The examples I gave were Fresco/ACE and Microsoft migrating to .NET.
> If you want more, let me offer this insight.  Has it ever struck you
> that hundreds of open source projects exist in pre-alpha or alpha
> stages, many of them doing the same things, with very few in mature
> development?  Just browse SourceForge to see what I mean.  (There is
> another concrete example:  poll SourceForge project version numbers.)

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 ? I think it's more related to the driving factors for
the people involved. More often than not the interest is only short 
term, the people accomplish their goal, i.e. they learned what they
wanted to know and then move on to other activities. That's life,
and we have to live with it.


> If IDL components were as attractive as originally promised, then we
> should see instead a snowball effect.  Each succeeding generation of
> code could build on the components of the previous one.  I don't see
> that happening.

I do, even though it is not an effect specifically involving IDL, or
'code reuse' in that strict sense at all. (sometimes it even is).

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

> The example I gave about forever forking was Prague, which someone
> on this very list admitted duplicated work even when it was first
> under development.

Why are you against duplicating work. That's unavoidable ! What are
the alternatives ? If I know upfront all the requirements I have, and
if they coincide with what ACE has to offer to an important degree,
I may consider using that. But that's not how Prague evolved. Instead,
I had very limitted and specific needs, which I was able to implement
rather quickly, and without as big a resource requirement as ACE has.

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

[licensing]
> I don't know how to be more concrete than by saying what I've said.
> I've offered multiple examples of the pitfalls that business faces
> in using LGPL code.

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.

> Your argument is that Fresco does things that nobody will want or need
> to change, and that if I understood Fresco better, then I would
> recognize this fact.  However this "fact" is something no one can
> prophecy, any better than one can prophecy the life cycle of an open
> source project.

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 ? What I find so cynical
here is that we do offer much more power than proprietary alternatives
(in terms of the ability to influence the directions of the development,
and in terms of actual code), and yet you accuse us of being 'business-
unfriendly'. That just doesn't fit together, though it is unfortunately
a very common 'argument'.

Regards,
		Stefan