Peter Donald wrote:
On Tue, 26 Nov 2002 11:04, Stefano Mazzocchi wrote:I agree with you that ECM is crappy code. And you know that in order to implement Cocoon Blocks, we'll need a much more modern (and thought-out) container and that in order to be able to do that, we might even allow some back-incompatible changes (for something like Cocoon 3.0) where it does make sense to break compatibility.
I have documented most of the problems and strategies I have tried with respect to different packaging units. It is not yet in a format I can send and I posted to cocoon about it but no one responded so I didn't bother putting any work into getting it into a format that could be read by others. If you want I can try to do it sometime soonish - probably next Wend (a week and a day) from now would be easiest if you want.
That would be *immensively* helpful.
However I don't think that there needs to be any serious backwards compatability changes to enable it.I'm pretty sure that nobody will object changes in the cocoon internals if there is a way to provide (even a minimal) back compatibility for the cocoon 2.x components that users might have written for themselves.
I repeat: nobody is against having to change the cocoon internals to follow what the Avalon community decided (we don't want to be stuck on a framework that is considered obsolete by its own community) but all of us are *seriously* concerned about the impact of these changes to the current user community.
As you said in another post, a migration path must be provided.
I think it would be good to upgrade to fortress as soon as possible - as soon as Marcus (or someone else) integrates XFC or writes an ECM compatability layer it should be ready for release and should mean no backwards incompatability.Yes, I'm looking forward to that, but I think most cocoon developers don't understand the issues that we are trying to solve here, so maybe a detailed document might really help.
The one problem that I can see is that Fortress uses jdk1.3 Proxies, which may mean that it is best if someone looks at the code in either openejb or jboss that does proxies for jdk1.2 (or alternatively creates a jdk1.2 compliant proxy using BCEL).
Hmmm, good point.
If Cocoon was to do this and provide clear warnings of which artefacts are no longer recomended (ie marker interfaces to indicate metadata) and print out warnings to the logs/console then this should give your users a year or two to upgrade without any negative consequences.
Yes, that makes sense.
If you decide to go with a richer metadata model for Cocoon3.x (which would rock) then I think you should wait until the dust has settled here and there is a significant advantage to the upgrade.Most definately. I agree. The problem is that I need a better container to implement cocoon blocks and I don't know what to use :( and i don't want (for many reasons) come up with my own.
You have read the discussions on cocoon-dev about cocoon blocks, how would you proceed?
Besides upgrading to richer metadata I believe it will also mean you have to slightly "twist" your design to get better performance and ease of use. Basically moving to a more service orientated architecture and away from the container as a resource manager. However I think that is way off in the future so probably not useful to talk about it now.I'm *way* open to suggestions on how to make thing better on cocoon land, but only if they don't impact too much the community dynamics there. This is because I care more about the community than I care about technical excellence (and sometimes, they don't go along very well).
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
