[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Do we need a less platform dependent context provider registry?
|
I can certainly see the benefit of describing a high-level registry
service/class. I think it essentially has
the functionality that we ascribed to IdASEndpoint. This can be
implemented on top of the
java.security model or the plug-in model, but we have to decide exactly
what a Provider is,
and how we want to present this to the user. At the F2F in Boston, we
lumped "provider"
and "factory" together, but we've been having trouble with the
terminology since then.
It seems to me that a Factory is responsible for creating and managing
Contexts of a single type,
which uses a specific technology (or set of technologies).
A Provider is a more deployment/packaging idea -- how does a vendor
provide code that
implements various kinds of Contexts? In the plug-in model described
below, it appears that
the provider (plug-in) is responsible for implementing one, and only
one, factory class. In the
java.security.Provider model, there may be several kinds of factory
associated with a single provider.
We need to decide whether (and how) this vendor-oriented Provider view
should be presented
to users. The simplest thing, IMO, is to only talk about Factories (as
defined above), and we
can have an ImplementedBy attribute that lets the user choose a
particular implementation, if they care.
(We can call these "providers" if we want, as long as we make it clear
what that means. It's true
that the functionality we assigned to IContextProvider is more than just
Context creation, so "factory"
might not be a broad enough term.)
That's my two cents...
Paul Trevithick wrote:
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
