Noel J. Bergman wrote:
Stephen,OK, let me back-track a little.
Yep - the thinking I have concerning Locator is that it represents a
single context domain.
I think I see the issue, perhaps. To translate terms, your locator seems to be a context domain, not a context. In my model, a context knows only about context domains, not other objects. Client code never sees a context domain directly; they are opaque inside the context. The role of context is to figure out which context domain handles the URI. It delegates everything else to the context domain. Therefore, I don't want a consuming component to see what you call a locator when it is looking for something. I am asking for that outer wrapper.
Take the following scenario:
public void contextualize( Context context )
{
File file = (File) context.get( "urn:avalon:work" );
}
The implementation of Context in the above example could be:
public Object get( String key ) throws ContextException
{
return m_locator.locate( key );
}
In this scenario, the locator managed by the context implementation is simply implementing the notion of key based lookup. This is independent of any issues concerning context domain - i.e. the value proposition is a standard interface (Locator) that can be implemeted by components that act as the provider of the service of locating objects based on requests when embedded inside things like Context, ServiceManager or ComponentManager instances.
This specifically addresses the ability for the introduction of custom locator implementation within a containement environment - where implementation differentiate themselves in terms of (a) the context keys they support, and (b) syntatic sugar that thay can provide.
But lets take a step forward in complexity and consider a Locator that is acting as a locator of other Locator instances (which is getting very close to you notion of context implemetation as the access to a context domain).
public void contextualize( Context context )
{
// classic context
File file = context.get( "urn:avalon:work" );
// narrowed to a context domain
StandardContext standard =
(StandardContext) context.get( "urn:avalon.standard.context" );
// using context domain
File work = standard.getWorkDirectory();
}
When we look the above example we are seeing two types of usage. First - context as a context domain lookup, and secondly, degenerative lookup in the case of "urn:avalon:work" which is presumably redirectred to the "urn:avalon.standard.context" context domain. The aspect of casting can be handled via a proxy that simply presents the m_locator interface as an instance of Context and StandardContext (based on info associated with the locator service defintion).
So far we are looking at examples where there is one locator object that is handling the implementation of the Context instance. Based on your emails together with Leo's summary, there is also the potential subject of the management of multiple context domains.
public void contextualize( Context context )
{
// narrowed to a context domain
StandardContext standard =
(StandardContext) context.get( "urn:avalon.standard.context" );
// narrowed to a context domain
EnterpriseContext enterprise =
(EnterpriseContext) context.get( "urn:avalon.enterprise.context" );
}
In the above example, while we may be accessing different context domains, this is for all intensive purposes transparent to the client. To more completely present this scenario, lets include the root context as context domain:
public void contextualize( Context context )
{
SystemContext system = (SystemContext) context;
StandardContext standard = getStandardContext();
EnterpriseContext enterprise = getEnterpriseContext();
}
In terms of implementation, we have a locator that implements SystemContext that is being proxied under the Context interface. It provides values based on keys and support for convinience operations as show above. These convinience operations happen in this example to be returning different context domain objects - but as far as the locator service is concernined, its simply providing a sealable, proxiable lookup mechanism.
:-)What your describing is almost one-to-one with what I have in mind withI think we are agreeing.
the locator abstraction.
I keeping my fingures crossed and hoping that after readying the above you will still be agreeing!
OK - let me rephrase this - I'm seperating the notion of resource location from the notion of what is context. I am also also stating the an implementation strategy for a locator solution can be container dependent, and finally, that the defintion of thigns like keys are part of the locator service definition - not part of the component.
The only difference is that I'm seperating out the
context domain as a meta-based service within
supplimentary information concerning keys.
That feels like implementation, not architecture.
You will have probably noticed that I'm not making a computation distinction between context domains - the descriptions provided above deal with a root contex domain (established by a locator and typically proxied into a interface object). Access to alternative context domains is assumed to be via classic context access mechanism (i.e. basic object lookup). If I understand correctly, what I'm proposing would meet the seperation requiremets your outlining without the need to take that abstraction into the implementation. Does that sound reasonable (and it's my turn to say that at 3:30 in the morning is possible that it's unreasonable).Any time you see a <type> ... </type> - keep in mind that
this can be build programatically and supplied to an assembly
engine, and then pumped to a client. I.e. if your coding on
the contaier-side, creation will be drop-dead-easy.
I am working (as we speak) on a dynamic component model -We had previously agreed that everything that could be expressed via XML
its a model in which the meta data is not derived from static
information, but instead - its build and maintained at
runtime.
would be supported via API, so I didn't feel it was necessary to reiterate.
I'd like to suggest that things be kept simple, clean, and
flexible.
Which is why I'm thinking/focussing on single context domains for the
moment.
Priority for me is to be able to deliver a single pluggable context
domains / service domain.
My belief is that we need the context / context domain separation I raised in order to achieve "the pluggable context domains / service domain" that you are stating as a priority.
:-)
This is my thinking too - if the Context object is associated with exactly one interface type (Context or an interface derived from Context), and that interface defintion includes key specifications, we a rather solid platform.I'll make a further claim. The interface to Context will be more stable than the interface to context domains, especially during early development. That is OK because my components don't see the context domain interface.
Cheers, Steve.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
