Stephen,
> 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.
> What your describing is almost one-to-one with what I have in mind with
> the locator abstraction.
I think we are agreeing.
> 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.
> 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 -
> its a model in which the meta data is not derived from static
> information, but instead - its build and maintained at
> runtime.
We had previously agreed that everything that could be expressed via XML
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.
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.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
