Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Proposed Configuration Layout for Context Providers

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</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 list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
  


Back to the top