Re: [higgins-dev] Context Termionology (was [IdAS] use cases)

[Greg Byrd <gbyrd@xxxxxxxx>]

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