Re: [Avalon4:PROPOSAL] Context Consensus

my previous replies I forgot to send apparently, so here it goes...

On Wed, 2002-12-11 at 00:23, Leo Sutic wrote:
>                            RECAP OF POINTS

this is a good recap :D If I don't reply, it's cuz I agree...

> OPERATIONS
> 
> There is not consensus on whether the Context should have any active 
> operations. Stephen and Berin,

me too :D

> for example, advocates that any active 
> operations should be exposed via the ServiceManager, and that the Context 
> should only be used to fetch data. (Note: By active operations, I mean for 
> example requestShutdown().)

> There is currently *not* consensus that a component should be able to 
> specify any interface that it should be able to cast the context to. That 
> is, for every class/interface T,
> 
>      public void contextualize (Context context) {
>          T myContext = (T) context;
>      }
> 
> the component should be able to declare that it expects to cast the context 
> to a T. (For a less abstract example, replace T with BlockContext.)

note: the main reason I don't like this is because it means the
container impl must do proxying, which is heavyweight.

> ISSUES THAT HAVEN'T BEEN BROUGHT UP - INPUT SOUGHT
> 
> 1. A list of canonical keys and their meaning can be found at:
> 
>      http://jakarta.apache.org/avalon/excalibur/info/context.html
> 
> Should these be made Framework-wide canonical keys?

yes.

I think we should have the general agreement that

_if_ an avalon container exposes a piece of information through the
context using the get method, and _if_ this piece of information has a
particular class associated to it, _then_ the key should be the same
throughtout the world to the maximum extent possible. And "the world" in
this case starts at the framework level.

> 2. Should the context entries include an "isOptional" attribute:
> 
>    <entry intent="avalon:work" type="java.io.File" is-optional="true"/>
> 
>     ?

I think this is a nice experimental feature that need not be supported
in avalon framework 4 till we figure out if it is truly needed and in
widespread use. There's other is-<blaat> things one could think of. I
suggest keeping it out of the proposal.

cheers,

- Leo