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 imagine these could be combined somehow if you've got an idea but the Context Factory may need it's own configuration, for example for pooling settings etc.  I suppose the global Context Provider section we have could serve the same purpose but the one was for the Context Factory and the other was for all Context Providers so I separated them.  What were you thinking there that would serve both the interim and XRI resolution?

Tom

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 05/25/07 1:42 PM >>>
I'm not clear on the need for different configuration for a context factory and a context provider.
 
Also, the XRI/XRDS proposal (as I understand it) will have a resolver examining a context ID (URI) and finding an XRDS service endpoint which will contain the context config.  After finding that, the context provider/factory config is found (using the value of the <type> elements).  So that model has a much looser coupling between the two kinds of configurations, and resolution happens backward from what's below.  I'm not sure how consequential that is to this interim solution, but it might be good to get some relatively similar practical experience if we model the interim solution more closely to the proposed XRI/XRDS solution.
 
I'm using http://wiki.eclipse.org/index.php/IdAS_Registries_Proposal_2B as a reference
 
Jim


>>> "Tom Doman" <TDoman@xxxxxxxxxx> 5/25/07 11:10 AM >>>
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