avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrell DeBoer <darr...@apache.org>
Subject Re: reduction ad unum
Date Sat, 23 Nov 2002 23:00:26 GMT
>From another branch of this thread:

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.

(I've replied to this in-thread.) 
I believe this solution is superior to extending the concept of a Context. 

If we can limit the use of "Context" to a very small set of standard entries, 
and use the regular service-dependency mechanism for anything that might be 
remotely container-specific, we avoid making this more complicated than it 
has to be.

To be honest, I'm not sure we'd lose much by ridding ourselves of 
Contextualizable altogether - maybe make Context just another service (the 
service ;).
Darrell DeBoer

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

View raw message