avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: Zen Framework (was Re: [avalon] roadmap)
Date Thu, 04 Mar 2004 09:55:46 GMT
I've read through the emails on this thread, and basically we're
at the point where everyone is right - given their context.

Is simplicity good? Sure. But some complexity is needed if you want
to do complex things.

Are hard contracts good? Sure. But you'd better get the contracts
right, otherwise you'll constrain users too much for the framework
to be useful.

The ideal appears to be a one-sentence contract that is rigid as
an steel bar, and which enables you to implement an application
in one line of code.

So how close can we get?

This is my suggestion:

First, let's drop the "big container" approach. Just like "big
government" it puts a whole lot of functionality in the container
itself, and not in pluggable modules.

I want a small container microkernel that can be configured with:

 + Component handlers (Appliances in Merlin)

 + Cross-cutting concerns (such as logging). Selectively
   applied to different handlers/appliances.

That's it. All the container should do is make sure
component A can get at its dependencies, and that the cross-cutting
concerns are applied. Nothing more. Everything else should 
be factored out and made pluggable/ignorable.

Fortress went wrong in my opinion when we included logkit 
configuration, async release and God knows what.

Merlin went wrong when it turned itself into an application
server with property files and all, and when you needed
a dictionary just to understand the docs.


Example of Conceptual Simplicity
--------------------------------

Let's look at UNIX. (Everyone loves UNIX.)

    "Everything is either a process or a file."

Can we say the same thing about the environment of our 
containers?

Merlin:
In Merlin everything is either a service, platform, component,
block or root block, "implementation solution", type, template, 
service definition, profile, container, kernel, resource, 
repository, directive, appliance or appliance instance.

Fortress:
In Fortress you have components, roles, instruments, selectors,
component handlers.

It's just too much.


Goal
----
Basically, is it possible to shrink the number of concepts
required to understand the container? How much?

Let's see how much terminology we can throw on the scrap 
heap. I'm convinced that really smart people such as ourselves
can describe really complex things using really simple
words.

Suppose we can say that "everything is either a X or Y". Then
we can define X and Y as interfaces, make them pluggable
and off we go.

/LS



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message