| Re: [higgins-dev] Do we need a less platform dependent context provider registry? |
|
Random thoughts after catching up on recent mails:
I agree with describing the roles of a context provider as well as the notion of factories and registry in abstract terms first, and then looking at how existing technologies might be adapted to fill those needs.
Before the last F2F, I (like I think Greg said) assumed a context provider was just a term we used to talk about the grouping of classes which implement the required IdAS interfaces.
I also assumed that there would be some kind of factory interface, and that it would be the combination of the factory class name and configuration data that the user (IdAS consumer) would need to pass into something (which we ended up calling IdASEndpoint) in order to get back an instance of IContext.
That two providers can produce the same context is foreign to my thinking, but if there's a need for that, ok.
I'm not sure of the reasoning behind some of the use cases (like 3, 4, and 5). I'm looking at JNDI as an example of a very similar system. The user just specifies the factory name and some config data. There's no way of enumerating providers, nor is there a built-in way of knowing what the underlying store is, or even the implementor for that matter (though both of those are typically well known if only via the factory's class name (com.ibm.jndi.provider.dns.ContextFactory)). Maybe IdAS users are more sophisticated and need different ways of interacting with providers and the contexts they produce?
I'll go read the latest wiki... >>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 7/21/06 6:30 AM >>> Greg and Jim, I just moved the registry-related text to its own page http://spwiki.editme.com/ContextProviderRegistry and linked to it from the main IdAS page here: http://spwiki.editme.com/IdentityAttributeService. The new page describes the current and proposed Context Provider registration approaches. In addition to different functionality/semantics, there is also a difference in technologies. It occurs to me that if we're going to go to the trouble of replacing the current provider registry, perhaps we should move in the direction of something that is less platform dependent. The current code is tightly bound to the Eclipse/OSGI plug-in runtime. The new proposal is tightly bound to Java and java.security.provider. Maybe we should use this opportunity move to a more abstract services description. If so, this might allow an implementation of the service on the Eclipse platform that uses Eclipse/OSGI plugins, and on other platforms using java.security.provider, and yet on Linux/C platforms using something equivalent. -Paul _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |