Giacomo Pati wrote:
On Tue, 3 Jan 2006, Sylvain Wallez wrote:
Right. And the simplest and most consistent step to go forward is IMO
to just use what's already there, providing a nice bridge to a
rock-solid container used by thousands of people.
If you mean Spring as the "rock-solid container used by thousands of
people" than tell me why are you using a Mac while "ten-thousands of
people use a IBM ThinkPad" ;-)
A very interesting comparison: Apple is currently moving to Intel CPUs!!
Why so? Because PowerPC is a dead end for their market, as IBM makes no
effort to produce good laptop CPUs. So Apple changes the engine, without
changing what's unique to them.
This is exactly the same for Cocoon: Avalon is dead, and we all agree on
this. So what's the point of adding dependency injection features to
Avalon? It's like adding Intel instructions to a PowerPC to prepare
migration. That's nonsense: you end up with a clumsy solution that
smells like a DI container but is not, and provides a mix of injection,
lifecycle interfaces and service lookup. Furthermore, it doesn't really
encourage people to move away from Avalon as its features are still
available to all components.
That's what I'm against this change to ECM: just as Apple has setup a
bridge (Rosetta) to allow PowerPC and Intel code to run on the same
hardware, let's have this bridge in Cocoon too. Want to use legacy
components? Use ECM. Want to use dependency injection? Use Spring. Or
Pico. Or Hivemind. The bridge can host whatever container manager you
want, even if we should promote only one.
From a user point of view, I'll be happy to see soon PowerBooks as
powerful as ThinkPads. But there's actually much more to this switch: it
won't take long before wine is ported to the Mac, so that we can use
some applications that, like it or not, only exist on Windows. Yes: the
comfort of the Mac, with is "deviant" compared to the vast majority of
PCs out there, but the ability to suck Windoze applications when it
makes sense.
This is the same with Spring: this is not only a DI container, but a lot
of additional services to build applications. And also a lot of people
that know it.
The Cocoon project, in its current state, really doesn't need yet
another specific extension to its obsolete container architecture, that
less than an handful of people will understand and be able to maintain.
We need to move away from Avalon, so let's do it in a way that can bring
in more people and use an engine that's known outside of cocoon-dev.
I can understand Carsten as we've talked about it recently and we
share some common reservation about Spring (as Carsten has already
expressed). Maybe Carsten regrets having written that Spring bridge or
the motivation to write it was a business or marketing need not a
conceptual evolution.
I asked Carsten why he doesn't want to use the bridge that _he_ wrote,
and would love to have his answer. Carsten?
So, after your veto to the change Cartsten has proposed the only way
for him is to write another bridge that suits his needs. This is what
I was calling ECM+++.
Admittedly I do not know how this bridging to Spring is done at all
and I cannot say whether or not a migration from one CM to another
will be possible to smooth this migration so that one day we can
deprecate the usage of Avalon components.
Have a look at the "spring-app" block.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
