On Sun, 24 Nov 2002 00:35, Stephen McConnell wrote: > In every single one of the examples you have provided above, the > extension of context is related to the exposure of a service. Take the > "forwardMail" example and image we want to create a component that is > complete and container agnostic. What we would do is declare that the > component in question has a dependency on a MailForwardingService. The > contract says nothing about where the service comes from (could be the > result of assembly, could be the result of a facility supplied by a > custom container). The point is that using *existing* Avalon Framework > contracts - this sort of dependency can be expressed providing we have a > consistent component model. Combine this with standard context entries > (avalon:home, avalon:work, etc) and the whole requirement for context > specialization disappears - or is at least pushed out into relatively > closed environments where component reuse outside of a particular > technical domain is of no interest.
This makes heaps of sense to me. The idea of a "MailForwardingContext" is a perfect example of something that doesn't really fit the concept of a *context*. It's really a *service* that provides the ability to forward mail. A "ShutdownRequestContext" could, likewise, be seen as a *service* which provides the ability to shutdown the container. The container may or may not provide that service to certain components. Following that, even the "DirectoryContext" (used for getBaseDirectory() etc) could be seen as a "FileSystemService". (I'm just suggesting this as a *possibility*, not necessarily *recommending* it). Imagine the possibilities of using a Virtual File System (see commons-sandbox-vfs), so that the component could be transparently be switched from Local file system, to WebDAV, to zipfile, to whatever. The way I see it: 1) We need a way for a component to declare it's dependencies on services. 2) Why should we invent another mechanism for container-specific contexts, where 1) would suffice. Of course, there may well be a small set of contextual information which should be provided as part of the Context. Maybe a FileSystemContext makes sense as a generic extension to Context, which almost every container would provide. But the point is that such examples are few, and *all* can be treated as services, until such a time they become so universal that they require special treatment. -- cheers, Darrell DeBoer -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
