avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [Proposal] AMTAGS Pt. 2 (the opt-out clause)
Date Fri, 25 Jul 2003 17:44:35 GMT

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 implement?

  That's fine - it just means that the container
  documents that fact that it does not provide
  support for the particular tag and includes at
  least some form of graceful failure if a
  component declares a unsupported constraint.

* Optional to recognize?

  That would defeat the purpose of the specification.
  We would simply be regenerating another insufficient

So what exactly do you mean by optional?

> 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.

> While they make certain things like dynamic assembly a workable reality, 

These tags have nothing to do with dynamic assembly. 

> 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.

> 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 believe this is a reasonable request. 


> 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.



Stephen J. McConnell

Sent via James running under Merlin as an NT service.

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message