Re: [Proposal] AMTAGS Pt. 2 (the opt-out clause)

[Stephen McConnell <mc...@apache.org>]

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

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.

Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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

Re: [Proposal] AMTAGS Pt. 2 (the opt-out clause)

[Leo Simons <le...@apache.org>]

Steve,

Stephen McConnell wrote:
> That would defeat the purpose of the specification. We would simply
> be regenerating another insufficient specification.

<snip/>

>  Is this not falling back into the
> AMTAGS V1 trap - the insufficient specification that won't deliver on
> its promise.

could you please spend an afternoon reading about extreme programming,

http://www.extremeprogramming.org/

for example. Disregard the cheesy name. You really don't get it. Any 
specification not developed according to at least some of the principles 
underlying XP (in particular, incremental development) is going to be 
subject to overspecification. Overspecification is worse than 
underspecification.

Of course, if you actually follow XP-style methodology, the need for 
specification goes away as the specs are encoded in the unit tests.

"AMTAGS V1" does not promise anything. Nor should V2 or V3. You guys 
should just write avalon-meta and implement it in our three containers 
without worrying toooo much at this point as to whether an attribute 
will be optional or not and how exactly that is to be worded.

The real world will show what parts will go unused in the majority of 
systems, and those parts you can then dub optional.

all IMNHSO.

cheers!

- Leo



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

Re: [Proposal] AMTAGS Pt. 2 (the opt-out clause)

[Stephen McConnell <mc...@apache.org>]

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:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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

Re: [Proposal] AMTAGS Pt. 2 (the opt-out clause)

[Berin Loritsch <bl...@apache.org>]

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.

For instance, I am coming from a Fortress/Phoenix world where these tags don't
currently exist.  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.  If my
existing functional components don't have to be altered then I am 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.


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

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

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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