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 Sat, 26 Jul 2003 12:23:57 GMT

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.


Cheers, Steve.


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