On Tue, 3 Dec 2002 02:23 pm, Stephen McConnell wrote: > >Third, how would you phrase the distinction between Context and > >ServiceManager? What is the key issue, in your mind, that separates > >items made available via Context and those made available via > >ServiceManager? How would you elucidate this to someone new to the > >Avalon Framework? > > There are two views you can take here: > > * the state/service separation > * the container/peer separation
This is the basic problem, it seems. These 2 dimensions just don't fit into Context.get() and ServiceManager.lookup(). How does a component writer ask for, say, a container-provided service, or peer-provided state? Or a particular service, whether container-provided or not? It would be really useful to take a step back and decide which of these groupings actually add value for the component writer, and are worth keeping distinct. Maybe both are, maybe neither are. Then, model the groupings explicitly in the framework interfaces. For example (and, please, they're nothing more than examples): If neither state/service or container/peer separation is useful, drop one of Context or ServiceManager. Change the contract of the remaining interface so that it delivers all resources (apart from Logger, config and params) to the component. If state/service separation is useful, change contracts so that, say, Context delivers state, and ServiceManager delivers services. If container/peer separation is useful, change contracts so that, say, Context delivers container provided resources and ServiceManager delivers peer provided resources. Probably rename ServiceManager to something more appropriate. If both are useful, well, there are a bucketload of ways to model that. Unfortunately, none (that I can think of) really appeal. > My current thinking on this is that we need a separation notion - > *privalided" services and context dependencies. The notion of a > privileged service or context simply means "the container is responsible > for providing the service" and distinct from "the container is > responsible for mediating the service". If we were to provide two > FileService instances, one being privileged and other non-privileged - > the "non-privileged" notion corresponds to a peer, whereas the > privileged notion implies responsibilities on the container. So this would be a possible solution to the 'both are useful' case above. Presumably a component would be able to ask 'give me the non-privileged such-and-such service', or 'give me the privileged such-and-such state', or even 'give me the such-and-such service, I don't care if it's privileged or not'. Do you really think this is going to be useful to the component writer? Do you have some examples? -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
