avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <adammurd...@apache.org>
Subject Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Tue, 03 Dec 2002 12:38:07 GMT
On Tue, 3 Dec 2002 08:52 pm, Peter Donald wrote:
> oops - sent when I meant to save as draft and finish later ... I clarify
> now then.
>
> On Tue, 3 Dec 2002 21:45, Peter Donald wrote:
> > On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
> > > Sure.  These are good examples of why everyone wins when there's a nice
> > > match between what a resource means to a component, and how the
> > > resource is delivered to the component.  If the component wants a
> > > logger, give it a logger.  If the component wants config, give it
> > > config.  etc.  Maybe the same resource is presented in different ways
> > > depending on how the component asks for it.  Maybe not.  Component
> > > doesn't care.
> > >
> > > But the examples don't really answer the question:  Why is it useful,
> > > when a component asks for a resource of a particular type, to
> > > distinguish between resources of that type that are provided by the
> > > container, and resources of that type that are provided by other
> > > components?
> >
> > I don't really understand what you are getting at. 

Yeah, good question :)

I don't necessarily want to change anything.  I started off wondering what, 
exactly, Context is all about; What it means, and what it gives me as a 
component writer.  The framework doesn't clearly define what a Context is, 
and the interface itself is useless: Object get( Object )?  Please.

And it seems there is no real consensus on avalon-dev about what Context 
means.  In fact, avalon-dev seems to advocate using Context for 2 unrelated 
things:
* Container-provided data and services.  Peer-provided services end up in 
ServiceManager, and presumably there's no such thing as peer-provided data.
* Data (presumably container-provided, but not really clear).  Services end up 
in ServiceManager. 

All warning signs:  A poorly-defined contract (or poorly understood, at 
least), a hyper-abstract interface, 2 separate usages, unresolved discussions 
about what it should mean.  All suggest something's wrong with the current 
abstractions.  Maybe there's a new abstraction that needs to be split out; 
maybe a real abstraction has been fragmented; maybe there's an artificial 
abstraction that needs to be done away with.  I don't know.

To me, the best way to figure this out to start with the 2 use cases above, 
and question whether they really are useful to a component writer.  Once we 
know that, the solution is considerably easier:

* If it turns out that neither are really beneficial, well, then there's no 
real point in keeping Context.

* If it turns out that one use case is beneficial and the other isn't, tighten 
up the contract on Context to reflect this.  And maybe make Context and 
ServiceManager consistent like you've suggested.

* If it turns out that both are beneficial, we have some more work ahead of 
us, as neither Context nor ServiceManager reflect this.

So, I'm not advocating any code change, because I don't know what form that 
should take.  Hence all the questions :)

-- 
Adam

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


Mime
View raw message