[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Proposed Configuration Layout for Context Providers
|
I guess we should revisit the discussion of the relative lifetimes of
Contexts and DigitalSubjects.
I had the impression that a Context could be created at runtime - and
therefore should not require re-configuration.
Maybe I am wrong.
Thanks,
Mike
higgins-dev-bounces@xxxxxxxxxxx wrote on 05/30/2007 05:25:04 PM:
> 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
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
