cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [Proposal] Shared Objects & Services Architecture
Date Fri, 14 Jan 2000 00:09:01 GMT
Brett McLaughlin wrote:

[...skipped the well thought model...]

> Feedback
> --------
> This is an initial model, partially realized in my mind.  It is based
> heavily on Avalon, personal frameworks, and a dissatisfaction with the
> time spent to uncouple applications, or force users into _one_ (and only
> one) solution.  Right now, Cocoon and Turbine are two good solutions
> that are close to mutually exclusive; they certainly do not fit together
> well.  My experiences here intergrating the two (and rolling out a
> production application on Cocoon and a similar framework) are shown
> here.  Certainly it is not foolproof though, and I welcome all feedback.

I can see the Avalon influence and I'm happy about it. I can also see
your points when defining simple and general interfaces that extend
Avalon and allow components to be interchangeable.

I understand your concern and welcome your proposal.

But I think it doesn't work!

Let's look at your interface

public interface Component extends Block {
        public void set(Object ob);
        public Object get();
}

you need an object. the object could be: what if you need more? you
reply, pass a collection. Right.

Then what do you do? you cast the objects to what you need to operate.
But if the casting fails, your component is not able to work on that
request.

Which totally breaks the requirement.

Avalon is _very_ careful in _not_ specifying any "working interface",
but provides only orthogonal interfaces that provide hooks for the
component framework but do not influence it's operation directly.

There is no such thing as a "general interface for doing something", or
it's so general it doesn't really do anything.

Your component is actually an Executor

public interface Executor {
   Object execute(Object o);
}

which is the java-way of saying "do something with something and return
something" which is the abstraction of a "method".

Do you know why it was called Avalon? Avalon is the place where King
Arthur is supposed to be burried. It's a myth, it's the geographical
equivalent of the "holy grail": you know there must be a place like that
but you don't know where it is, you can only continue your search...

So, IMO, there is no solution to your dilemma, but higher integration
and collaboration.

It will take time, that's for sure, but we must be patient and do our
best to collaborate and to create a solid foundation.

For this reason, I welcome your proposal and I like your gradual
approach.

Still, I don't know what impacts your proposal has on the code base,
today. Would you, please, elaborate more on that?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message