My thoughts for the day.
A quiet weekend brings me to the open subject of the resolution of a the avalon component model and our support for the one true model. According to Silvian Wallez, the one true model is a step too far in the direction of too much magic. However - before we accept this as fact - let's do a little analysis on where Silvian is coming from.
I'm confident that Silvian would appreciate the implicit magic in ECM, for all intensive purposes it requires the obligatory usage of meta-info in component implementations via the ROLE static member. Let's not stop here - we also have the meta-data model implied (but not not specified) under a the ECM roles configuration. Silvian is absolutely correct - this is not magic. In effect it is an application specific deviation of of the Avalon component model. Again - Silvian raises concerns relative to Fortress - in particular the introduction of magic through the automatic generation of unspecified meta. In this context I agree 100% with Silvian.
Irrespective of my unbounded agreement with Silvian - I'm going to disagree with Sylvian on a very basic principal. The Cocoon community and for that matter all users of ECM and Fortress and are dealing with meta information. The mysterious ROLE static value is nothing more that the declaration by a component of the public service interface it provides - and yet where is the avalon documentation for this? It does not exist. Furthermore - the role file is pure loosely documented meta-data, mapping "role" names to implementation solutions. Rather than clearly and completely documenting these contracts (let alone expressing these semantics in a formal API), the existence of ROLE has been argued by a select few on the basis of "convenience" and even "the intuitive approach". In effect the reality is that undocumented semantics combined with a legacy implementation is the the only tangible definition of LSD's "too much magic".
Back to Sylvian - and another point of agreement. Sylvian expressed his personal support for the resolution within Avalon of a single community backing a single solution. However - Sylvian expressed less that a 100% conviction relative to this viewpoint. Why? I can't speak for Silvian but I can speak for myself. We have a potential catch 22. There is vocal minority that is expressing the opinion that we should not consolidate our efforts on one platform without an equivalent feature/benefit matrix so long as we have users of the another platform - and in the same breath - why consolidate when we have a solution? The real catch 22 here is that those who understand and appreciate the ECM/Fortress model have not yet committed to the migration.
Over to Hammett - and the religious conviction theme. Hammett and I actually agree on most things - but on this particular issue its black and white:
Hammett's position:
* don't abandon Fortress before equivalent functionality is in
place - in the meantime "may the force be with you"Steve's position
* forget about the "force" - its just a movie - focus on
reality and deliver the final solution as a collaborative
effort - reality is that the "force" is the community and
the community needs to consolidate and as long as we have a
division - the end-game remains elusiveSo here is the dilemma. Follow the Hammett strategy and destroy the dream. Follow the other strategy and take a risk. What to do?
How about the following:
* create the one solution community * maintain a fullback strategy * deliver more than we promise
In a somewhat related but independent thread Arron Far said (and I'm not implying anything but a good text-stream from Aaron):
One container to rule them all
One container to find them
One Container to bring them all
And in the model bind themAnd my answer was "yes" - meaning one model, total domination, no prisoners. But how to achieve this? I think that irrespective of the traffic - the consensus is reasonably close to closure. It's more about "how" than "if". The how is about accommodating different priorities with respect to a sustainable solution.
But maybe not. Chances are that I have this all wrong. Are there additional points we should be taken into consideration before closing this particular subject?
Stephen.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
