Leo Simons wrote:
Stephen McConnell wrote:
I think it's sensible to first get the LCD to actually be LCD before starting on growing it :D
Here is a better proposal - lets outline the expanded set of tags and get concensus on the suite.
problem: this is mostly uncharted teritory. Consensus will be difficult. I will need a few weeks of thinking before I will have an opinion on all the tags in use in merlin.
Here is a convinience link: http://avalon.apache.org/sandbox/merlin/tools/tags/index.html
And it is summer. So add more weeks :D
:-)
---
What we have in Merlin at the moment is a constent set of tags and incorporating the LCD subset would make things inconsitent.
you mean within a component using merlin-specific tags, or from the view of the merlin implementation. Within a component using AMTAGS it brings a tremendous amount of consistency if those will actually work cross-container!
Getting in place a full, complete and consitent tag set isn't such a big deal - the problem is that there is strong restance to the establishment of a standard tag that is not backed by a supporting implementation. This suggests that it probably will not happen - so the better solution is to maintain a conplete a consitent set that covers everything needed for full component declaration.
What is more important, consistency of compile-time container-specific tools or consistency and predictability of userspace meta API across containers?
"Write your meta data like this." "Now type 'ant fortress-parse-meta'." "It works. Deploy to fortress 1.0 or later." "Now type 'maven merlin:parse-meta'." "It works. Deploy to merlin 1.0 or later."
Only works if we cater for all of the requirements. I.e. the LCD approach fails the usability test.
---
I figure the better approach is to lay out the suite -
assertion: we (I) do not have sufficient use case knowledge and experience to be able to lay out the suite.
assertion: we (I) do have sufficient use case knowledge
Its not about the application scenarios - its about declaring the component meta info.
migrate Merlin to the AMTAGS model and deal with the much more important point of establishing well defined requirements on containers to deal with "unsupported" or "unrecognized" tags in a well defined and consitent manner.
you mean along the lines of
"Fail early
Fail early or ignore if appropriate.
Containers SHOULD report an error when they find a tag or property in the avalon namespace they do not understand, and they SHOULD NOT continue setting up the component the unknown property or tag applies to."
"@avalon.dependency
(...)
A container which does not support dependency validation SHOULD ignore this property.
Yep.
(...)
optional - specify whether the dependency is needed for proper operation of the component or not. A container MAY ignore this property."
Yep.
I think what is in AMTAGS at the moment is internally well-defined and consistent enough that it is quite possible to provide an unambiguous "conformant" implementation.
Problem is that it is totally insufficient.
Take a look at the Merlin and Phoenix requirements - AMTAGS should be addressing the full suite - not just the Fortress subset.
---
I think we should take advantage of strong namespacing ("complain about what you don't understand, if it starts with '@avalon'") to ensure predicatibility, and the implication here is "ignore everything you don't understand, if it does not start with '@avalon'". Sam Ruby's weblog (www.intertwingly.net) has a lot of interesting stuff about "ignore what you don't understand" philosophy.
---
AMTAGS is IMHO still up on the wiki for a reason.....namely it deserves some more attention.....surprise me!
Not yet - other things are holding my interest. But its on my radar.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
