[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Proposed Configuration Layout for Context Providers
|
I'm not sure I understand what you're getting at. Probably because when I read "Context", I think "somewhere there's something that points to a specific backing store or way of presenting data from some backing store" and therefore it comes off to my mind as "a given that each Context would be configured separately" because each Context defines a different set of data to draw from or perhaps even a different view of some common set of data. Regardless, a "separate configuration" would be required for each "Context". Is my thinking to narrow on this? Perhaps, I'm misdefining "Context"?
Thanks,
Tom
>>> Michael McIntosh <mikemci@xxxxxxxxxx> 05/29/07 7:34 PM >>>
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
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
