[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Proposed Configuration Layout for Context Providers
|
I think all ContextFactories should be configurable.
I am concerned that - by creating a configuration section for each Context
instance - we are creating a situation where creating a new Context
instance requires reconfiguration.
I am not saying that a particular ContextFactory can't manage its own data
(aka Contexts) thru Configuration, just that it should not be a given that
each Context would be configured separately.
Thanks,
Mike
higgins-dev-bounces@xxxxxxxxxxx wrote on 05/29/2007 08:08:19 PM:
> >...the other was for all Context Providers...
>
> So in the proposed XML, does {My}ContextProviderConfiguration
> represent config for all context providers in the deployment? If
> so, maybe we should use a different name like IdASConfiguration or
> GlobalContextProviderConfig.
> To serve the interim and long term solutions, I was thinking we
> could model it such that the context config and factory config were
> at the same level (sibling elements rather than one nested in another).
>
> Jim
>
> >>> "Tom Doman" <TDoman@xxxxxxxxxx> 5/29/07 10:08 AM >>>
> 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
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
