Berin Loritsch wrote:
Stephen McConnell wrote:
Berin Loritsch wrote:
Again, I am splitting this up into three threads. The first one is already
under way. Each thread represents a different level of concern.
In this thread, we are dealing with the context, logging, and configuration
meta tags. I personally do not have a strong oppinion against them. I can
see value for their existence. As the context and configuration aspects are
fairly Avalon specific, I don't mind them being in the Avalon namespace. I
do request that they be specified as *optional* meta information.
* Optional to recognize?
That would defeat the purpose of the specification. We would simply be regenerating another insufficient specification.
It would still be sufficient for some--just not everyone. Seriously though,
the difference between recognition and implementation is somewhat blurred.
What is the true difference between recognizing information to ignore it later
and simply not recognizing it at all? Its just semantics.
So what exactly do you mean by optional?
I mean optional to define. The AMTAGS proposal is about the component writer's
declarations to the container. What the container does with it is really up
to the container (to a point). IOW, I just don't want to force users to declare
an @avalon.context.entry for each value they use if it isn't important to them.
There is nothing here forcing a user to do anything. All we are dealing with is the provision of mechanisms whereby component authors can migrate. If component author does not want to migrate - then they can work within the semtics of a container. If the component author wants container independence, then we are providing a framework to assure independence. The choice rests with the component developer.
For instance, I am coming from a Fortress/Phoenix world where these tags don't
currently exist.
Declaration of context dependencies esist in Phoenix by implication and transformation. Phoenix declares meta-info in a <blockinfo> descriptor. The result of expansion of a block info descriptor is the creation of a Type defintion that includes all of the Phoenix assumptions concerning context entry dependencies (a process that is automated under the meta-info package).
If I now have to go back and add the meta info for all the
context entries just so that they can work again, then I have a problem.
No - you will not have to change a thing (unless you want thos components to run in containment environments other than Fortress).
If my existing functional components don't have to be altered then I am happy.
Good - they don't have to be altered. I'm happy your happy!
The logging attribute is more generic, but there is little point in defining a new namespace just for that concern.
Part of the reason why I am somewhat hesitant about them is because of the
cry for simplicity. PicoContainer, Fortress, ECM, and Phoenix (with the
exception of the configuration tag) all live quite happily without them.
How do container specific APIs, container specific context entries, and container specific casting constraints add to the simplicity of working with Avalon technologies? Is this not falling back into the AMTAGS V1 trap - the insufficient specification that won't deliver on its promise.
Nothing. I am just starting to chew on how to do the same thing without developer declared meta data. I don't even have a vague idea yet, but there has to be a way to make things work without having to half think about it.
There is a page that Aaron put together about context assumptions. On this, Fortress has a rather preponderouse number of context entry names that it uses. If I consider all of that, and if I consider Merlin management of context declarations (using the @avalon.entry tag), I can deliver Fortress based components and containers running in Merlin - if and only if those entries are published. This could probably be simplified by tools much in the same way the a Type defintion is magically generatd from the <blockinfo> descriptor.
I wonder how many developers will agree that they *have* to use it.
A developer does not *have* to anything unless they need to express a constraint - such as a context entry with a key, castable to a particular class, or the assumption that a context object can be cast to another interface. Developers don't *have* do any of this - presuming they are happy with the concept of container lock-in.
Of course if there are standard context entries, then they don't *have* to use it, and they won't be locked in to a container.
Just a small point here - when I refer to standard context entries I'm referring to the usage of standard names. I am not implying or suggesting that a standard context name must be made available. As such, the obnligation remains for a component author to declare a context assumption if they want to be able to migrate - we just simplify things by providing the commono standard names in which case they don't need to play around with container specific meta-data.
I like validation, and I think we should provide hooks so that developers
interested in validation and verification of their system can let it take
place automatically. On the other hand, I don't think we should make it
a mandatory thing for those developers with very simple needs. I.e. it
helps reduce the complexity of writing components for those who don't want
that complexity.
I understand the "mandatory" thing you suggesting here. There is nothing mandatory for the developer. They have choice. The context where mandatory should be discussed is with respect to the responsibility of a container to recognize the full suite of tags. Developers simply get to leverage what makes sense in their environment.
I'm glad.
My second concern has to do with the implications on implementation. As
long as I can choose any method I like to validate the context entries or
configuration, all is well. I don't want to be forced into a contract
between context entry dependency declaration and context entry definition.
The AMTAGS should be strictly applied to making the component writer's
life easy.
What's your point? If a componet author states he wants a widget and he's going to ask for it using the key "widget" - then a container should either fulfill this request or fail gracefully. The contract we are talking about is container "recognition" - recognizing that you can or cannot fulfill the expectations that a component has on a container.
Right. As things are defined right now, there is no problem.
Cool.
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]
