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
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
