Re: [higgins-dev] Proposed Configuration Layout for Context Providers

["Tom Doman" <TDoman@xxxxxxxxxx>]

Well, we may have some terminology problems as well here.  I think I've misused the term "Context Provider".  The Context Factory produces Context instances.  I'll avoid defining what a Context Provider is.  Each kind of Context Factory needs configuration that may effect how it produces it's kind of Contexts.  The Contexts themselves, of course, will also need configuration that will effect what identity data each produces.  This was why I included each Context configuration within the Context Factory configuration.  Based on this model, I'm not sure how multiple factories would come into play.

I could see each kind of configuration being in it's own section as Jim describes but I'm still working with him to understand how that would work unambiguously in the XRI world.

Tom

>>> Greg Byrd <gbyrd@xxxxxxxx> 05/29/07 4:12 PM >>>
I don't quite follow the full layout below.  Is this supposed to be the config for one specific context?

Shouldn't the factory configuration info be inside the provider configuration?  A CP may include multiple factories, correct?  For factory-specific settings, could use Mike's approach of a setting called "ComponentSettings" -- when an instance/singleton of IConfigurableComponent is created, its specific settings are looked up (by name) from ComponentSettings.  (A factory would be an IConfigurableComponent, right?)

...Greg


Tom Doman wrote: 

There are several consumers, pieces of functionality, and use cases that we have to support from a configuration standpoint in our Context Providers including:

1. XRI, XRDS
2. STS
3. Policy Decision Points
4. Factory Configuration
5. Multi-Context Shared and Context Specific Configuration

This e-mail stems from these areas.  For the moment, my biggest questions surrounds #1 and whether the general layout I'm proposing below is a proper usage of the configuration code.

So, I propose that our Context Configuration look something like this (followed by the "whys"):
<Setting Name="{My}ContextFactoryConfiguration" Type="htf:map"> <!-- Context Factory specific settings. --> <Setting Name="..." > ...
 <Setting Name="{My}ContextProviderConfiguration Type="htf:map"> <!-- Context Provider global settings. --> <Setting Name="jsPolicySharedScope" Type="js:jsPolicySharedScope"> <![CDATA[
 ...
 ]]> </Setting> <Setting Name="{Context ID 1}" Type="htf:map"> <!-- Context specific settings. --> <Setting Name="ContextConfig" Type="htf:map"> <Setting Name="Connection" Type="htf:map"> <Setting Name="Addresses" Type="htf:list"> <Setting Name="Address" Type="xsd:anyURI">ldap://localhost:50389 ( ldap://localhost:50389/ )</Setting> ...
 </Setting> ...
 </Setting> <Setting Name="consumerAIDToProvider" Type="jsPolicyAction"> <![CDATA[
 ...
 {References to share scope data here.} ]]> </Setting> ...
 </Setting> </Setting> <Setting Name="{Context ID 2}" Type="htf:map"> <!-- Context specific settings. --> ...
 </Setting> </Setting></Setting>
1. XRI, XRDS:  If I understand what has been proposed here so far, XRI will be used by the ContextFactory to resolve the XRDS document pertaining to the "{Context ID 1}" section above.  For this reason, I added an extra layer for the interim solution, the "ContextConfig" which will simply lift out into it's own XRDS document section.  In the interim, I'm assuming that the URI passed to IContextFactory.createContext() will simply be "{Context ID 1}" and the ContextFactory can use the configuration APIs to "resolve" that block and pass it to the Context Provider's configure() method.

2. STS:  The context ID stored in issued cards will change in the interim before XRI and post XRI but it will always have to contain the context specific ID used to produce the identity data.

3. Policy Decision Points:  JavaScript policy examples are included above.  Specific configuration handlers will be implemented and global settings shared.

4. Factory Configuration: The factory itself needs it's own configuration and, for the interim, it seems appropriate to have the Context global and specific configuration within the factory configuration since it will function as the interim "resolver".

5. Multi-Context Shared and Context Specific Configuration:  We'll have to preserve the Context global stuff when we move to XRI.  Not sure how that'll work.

Tom


_______________________________________________
higgins-dev mailing listhiggins-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/higgins-dev