Skip to main content

[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


Back to the top