Berin Loritsch wrote:
what about the thousands of user-written components out there who are *NOT* controlled by us?Nicola Ken Barozzi wrote: > > Berin Loritsch wrote: > >> Nicola Ken Barozzi wrote: >> >> > >> > Berin Loritsch wrote: >> > >> > >> > What about all the client code that checks for Component and won't >> find it in the Cocoon components, and the ones that extend Cocoon >> components? >> >> >> It won't break compilation. Cocoon component interfaces extend the >> (Component) interface so all the clients have to do to release is >> m_manager.release(foo); > > > You lost me here. > > We want to remove depecation warnings. Or we remove @deprecated, or we > remove Component from the Cocoon component interfaces. > > If we do the latter, as Vadim points out, this is not going to work for > our users: > > Component c = ((ComponentSelector)manager.lookup(Generator.ROLE + > "Selector")).select("something"); > > Basically all the code that casts to Component will stop working. > > I'm trying to see all the tradeoffs. >Not if we create a proxy. The ECM and FOrtress et. al. will continue working. The Component interface is added at runtime, and the Composable interface is supported by creating a proxy that implements the Component interface. Do a little experiment. 1) Upgrade the ECM used in Cocoon. 2) Remove the "implements Component" from the Generator interface. 3) Run Cocoon. BAM! It still works. _It has already been taken care of_
those will stop working if not recompiled. binary compatibility is lost.
that will force us to call the next release of Cocoon 3.0 because the binary components that expect Component will *NOT* work out of the box.
and we *DO*NOT* want to break binary back compatibility just because Avalon decided it's more *elegant* to do so.
All we ask is a smoother transition period.
We *will* make an effort to follow the path of removing the need for Component, but given our massive inertia (something that avalon doesn't have) we can't do it overnight as you ask without *major* impact.
Forcing us to break user code is not a win for us.
On the other hand, what we ask is to be more *tollerant* on past usages of the frameworks and start deprecating them seriously on 5.x where back incompatibility will be reflected in the name.
what avalon ask cocoon to do breaks its users code, what cocoon ask avalon to do doesn't.
I think it's time for avalon to grow up as a project and consider community dynamics more than pure technological value.
why? because the first builds best-of-breed technology slower, but stronger communities. the second builds great technology but those doesn't survive the persons promoting them.
the future of this project depends more on its attitude toward users than to its technological merits.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
Pluralitas non est ponenda sine neccesitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
