>>> 3) The containers that are in the works
>> I'm still wondering if we really need different implementations
>It can be that we will eventually come to a single design
Please be specific about what you mean? As I see it, the current division
of Avalon technologies makes sense to me:
* Avalon Frameworks - these are the basic contracts that
authors can expect to be guaranteed in all platforms,
plus some simple utilities.
* Avalon Excalibur - a major implementation of the
the Frameworks. But not the only possible one.
* Avalon Containers - container implementations.
Guaranteed to support Avalon Frameworks, and
typically written using Excalibur classes.
* Avalon Cornerstone - common pluggable services.
Best case says that they should run in any
proper container.
* Avalon Applications - a repository for "demo"
applications that don't have their own place.
Perhaps I am entirely wrong in my understanding of the conceptual division
of things, so I am open to correction. I am admittedly a little loose in my
definitions. The actual definition for Cornerstone, from the web site, ties
it tightly to the Phoenix container.
Doesn't such a division make sense? You have: interfaces, classes that
implement those interfaces, containers that support pluggable components, a
reusable library of utility components, and finally pluggable applications.
If I wanted to write a new Avalon container for a real-time environment on a
PDA, I ought to be dependent only upon the Avalon Frameworks. I could
CHOOSE to use Excalibur, or not. In a best case scenario, if I implement my
own container using nothing common EXCEPT for the Avalon Frameworks, I'd
like to be able to use Avalon Cornerstone components without their having
dependencies upon Excalibur classes; that may not be possible today - it is
a normative notion. And third party should not be dependent upon anything
not specified in Avalon Frameworks.
This is mostly about clean separation, but there are also packaging issues.
> Phoenix is released, proved and really stable. Think that someone has
> even gotten James working on a C# based JVM
That's true! LOL But how did you hear about it?
> Technically it seems sensible that there be one framework and more
> possible implementations. Community-wise, I'm not so sure.
Perhaps. But I think that the dependencies should be kept clean to permit
the option. Also, the cleaner the dependencies, the smaller the surface
area, and the more flexibility to change in the future.
> if we cannot come to a single implementation,
> probably it's because we still don't know how
> to do it.
Single implementation of WHAT, precisely? Frameworks? Absolutely.
Necessary. By defintion, there must be only a single definition of Avalon
Frameworks. Other than that, I'd prefer not to see any necessary
dependencies imposed upon container authors or upon components.
Let me point out that there are new notions coming within Java that effect
certain patterns of use. Such things as JSR 166 will have an impact, and
should. The same with java.nio.
Loose coupling is good. Perhaps the coupling areas need to be better
defined, and the loose coupling better enforced within the current code
(perhaps even shifting things), but the basic concept of organizing around
interfaces, classes, containers, and components seems sound to me. No?
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
