RE: [Avalon4:PROPOSAL] Context Consensus (version 3)

> From: Stephen McConnell [mailto:[email protected]] 
> >>>   The container must supply an implementation for all methods 
> >>>   in the interface. This may be done via a dynamic proxy 
> >>>   that routes calls to appropriate handlers or by any 
> >>>   other method.
> >>>      
> >>>
> >>suggestion: remove the above sentence.
> >>    
> >>
> >
> >I want to specify that this is container-specific. Unless this is 
> >specified, we get into abiguity:
> >
> >1. It is container-specific.
> >
> >2. It isn't, but the contracts are somewhere else.
> >  
> >
> 
> I agree with Leo Simon;s suggestion to remove the last 
> paragraph above. 

Changing it to:

"The container must supply an implementation for all methods 
 in the interface. The method of supplying the implementation
 is container-specific."

>  This does not conflict with the statement that implementation is 
> container specific (which it is).  The paragraph in question is 
> basically nothing more that a note concerning technical 
> implementation 
> which is really not part of the context contract.  However, 
> it could be 
> included in the package documentation as a implementation note.

Yes, that seems sensible.
 
> >>>   The set of methods that a container must 
> >>>   support is defined by the standard context interfaces in 
> >>>   Framework (currently none).
> >>>      
> >>>
> >>"a" container or "any" container? Regardless of the answer,
> >>if there are no standard context interfaces I'd say there 
> >>should not be a reference to them either. So again, I suggest 
> >>removing that sentence.
> >>    
> >>
> >
> >As above, I want it explicitly noted that there are none. 
> The absence 
> >of a statement to that effect can mean:
> >
> >1. That there aren't any.
> >
> >2. That there are some, but we've just not decided to mention them
> >   here.
> > 
> >
> 
> This is somewhat ambigouse.  We have already stated that if the 
> container is going to deploy a component it must do it in accordance 
> with the context contract - and the default for the context type is 
> org.apache.avalon.framework.context.Context unless otherwise 
> specificed. 
>  The class Context has no entry declarations - as such it is already 
> defined.  The existance of the above paragraph makes this less 
> clear.

The intent was that while there are none now, there may be some
in the future, but OK - since everything is optional (the note at 
the very top makes that clear), it should follow that a container 
need not provide any methods. Cutting that.

> >  
> >
> >>>2. The second parameter is a set of entries accessible via the
> >>>   Context.get() method and their types. The class/interface T 
> >>>   above may also have associated metadata that specifies entries,
> >>>   in which case these entries must be supplied by the container 
> >>>   in addition to any entries the component itself requires.
> >>>   Each entry requirement must specify the canonical key name, may
> >>>   specify an alias for the canonical key and must specify the 
> >>>   expected type of the value.
> >>>      
> >>>
> >>suggestion: change the above paragraph to
> >>"2. The second part of the context contract defines the set
> >>of entries the component can access via the Context.get() 
> >>method, where an entry consists of the key passed to get() 
> >>and the expected return type (ie the class or interface). 
> >>Optionally, an alias for the key name can be specified. The 
> >>contract associated with a particular entry is defined in the 
> >>container documentation.
> >>
> >> NOTE: It is our intend to specify common context entries and
> >>associated
> >>       contracts as part of the framework documentation. This step
> >>       have not been taken yet."
> >>
> >>    
> >>
> >
> >"2. The second part of the context contract defines the set
> >of entries the component can access via the Context.get() 
> >method, where an entry consists of the key passed to get() 
> >and the expected return type (ie the class or interface). 
> >Optionally, an alias for the key name can be specified. The 
> >contract associated with a particular entry is defined in the 
> >container documentation.
> >
> >The class/interface T
> >above may also have associated metadata that specifies entries,
> >in which case these entries must be supplied by the container 
> >in addition to any entries the component itself requires.
> >
> >NOTE: It is our intend to specify common context entries and 
> >      associated
> >       contracts as part of the framework documentation. This step
> >       have not been taken yet."
> >
> >Common metainfo/data is about to be introduced. I see no 
> reason not to 
> >include it here.
> >  
> >
> I think we can address the concern of referencing meta while 
> its undefined by including a reference to the Meta 
> Specification on the Context javadoc that simply points to 
> the a section in the context package documentation.
> 
> If we are going to mention meta then the description should 
> be updated to replace meta-data with meta-info.  Here is an 
> example within the appropriate package summary link.
> 
>   The context interface T above may also have associated meta-info 
>   that specifies entries, in which case these entries must be 
> supplied 
>   by the container in addition to any entries the component itself 
>   requires. Refer <a href="package-summary.html#meta">Context 
>   Meta-Info Specification.</a>
> 
> 
> The package documentation would contain the following:
> 
>   <body>
>   <a name="meta"/>
>   <h3>Meta Specification</h3>
>   <p> 
>   Specification of meta-information relating to context and 
> context enties 
>   is currently under discussion.
>   </p>
>   <h3>Implementation Notes</h3>
>   <p>
>   <!-- stick stuff here concerning container implementation 
> approaches -->
>   </p>
>   </body>

Yep.

Updating... (Please wait.)

/LS