[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [higgins-dev] Context Termionology (was [IdAS] use cases)
|
1. Did I ask this already? Are we planning to have each Higgins
implementor, implement their own IdASRegistry? That seems to be implied
by the outline below but I'm not sure why that'd have to be
reimplemented by everyone who wants to implement their own Context
Provider.
2. Yes, let's get back to your question about which Contexts are
registered and how. I'd like to see what you propose.
Thanks,
Tom
>>> Greg Byrd <gbyrd@xxxxxxxx> 7/24/2006 6:37 AM >>>
This is the line (from the Wiki) that separates the Higgins notion of
Context Provider
from the JDK notion of Provider:
* A Context Provider is a packaging/deployment wrapper around a
single Context Factory
If there's only a single type of Context associated with a Context
Provider, then
I don't think it's necessary to separate the notion of Provider and
Factory. We can
merge the two into Context Provider (as we did earlier), and we can
treat the
installation/configuration of Context Providers as a separate issue.
And, if this is the case, I don't think that the model needs to include
any notion of the
packaging/deployment issues. I recommend that we have a standard
attribute
(e.g., ImplementedBy) that identifies the vendor for cases where that's
of interest.
The user can specify that attribute in the filter for
getContextProviders() if needed.
In that case, the IdASRegistry service (was IdASEndpoint) has the
following:
(1) A registered set of Context Providers
(1a) An implementation-dependent way to configure a default list of
Context Providers
(1b) A way to dynamically add/remove/reorder Context Providers
(1c) A way to retrieve the metadata for a particular Context Provider
(2) A registered set of Contexts
(2a) An implementation-dependent way to configure a default list of
Contexts
(2b) A way to dynamically add/remove Contexts
(2c) A way to retrieve the metadata for a particular Context
NOTE: (1a) can be via the JDK Provider mechanism, the OGSi bundle
mechanism, or
some combination of these and others. A particular implementation of
IdASRegistry
must document the process that it uses.
Internally, we need a way to associate a Context with one or more
Context Providers.
And I would like us to eventually get back to my question about which
Contexts
are registered, and how.
...Greg
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev