| Re: [higgins-dev] Proposed Configuration Layout for Context Providers |
|
As Jim suggested, perhaps factory and context are siblings in the
configuration document -- the context config can have a setting that's
a reference to its factory. ...Greg Tom Doman wrote: Right, that's a good point about the Context ID being able to be independent from the factory/provider and I'll keep that in mind with the XRI details while creating a new proposal. Thanks, TomGreg Byrd <gbyrd@xxxxxxxx> 05/30/07 3:38 PM >>>In practice, we've been using provider and factory as pretty much the same thing. Each factory handles a particular type of context. A provider could package up multiple factories (supporting multiple context types). We've gone back and forth on this terminology -- see http://wiki.eclipse.org/index.php/Context_Provider. The goal is that a Context (represented by its Context ID) is independent from the factory/provider that instantiates the IContext object used to access it. At a particular moment in time, that Context has its data in an LDAP directory (for instance), and so it must be associated with a factory that will create an object that knows how to access that data. (There could be multiple factories that meet this requirement, e.g., from different vendors.) But it could move to a different type of backing store (e.g., Jena), without changing its ID, and would then need to be associated with a different factory. That's why the XRI resolution has to be in two steps -- first to resolve the Context ID to a service endpoint, and then to find the factory instance that can provide the identity data associated with the Context. That's why we're concerned (or at least I am) about the Context configuration data being inside the ContextFactory configuration data. It's sort of the other way around -- a Context's configuration data includes a reference to a factory type, as well as some factory-specific data that allows the factory to create the corresponding IContext object. ...Greg Tom Doman wrote: Well, we may have some terminology problems as well here. I think I've misused the term "Context Provider". The Context Factory produces Context instances. I'll avoid defining what a Context Provider is. Each kind of Context Factory needs configuration that may effect how it produces it's kind of Contexts. The Contexts themselves, of course, will also need configuration that will effect what identity data each produces. This was why I included each Context configuration within the Context Factory configuration. Based on this model, I'm not sure how multiple factories would come into play. I could see each kind of configuration being in it's own section as Jim describes but I'm still working with him to understand how that would work unambiguously in the XRI world. Tom Greg Byrd <gbyrd@xxxxxxxx> ( mailto:gbyrd@xxxxxxxx ) 05/29/07 4:12 PM >>> 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 ( ldap://localhost:50389/ ) ( 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 listhiggins-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/higgins-dev _______________________________________________ higgins-dev mailing listhiggins-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/higgins-dev _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |