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