RE: [higgins-dev] Do we need a less platform dependent contextprovider r

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

Greg wrote:
> 
> 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.  

Yes. BTW, are you planning to work on this service description too?

> 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).

Agreed. 

In the current code, there is no ContextProvider/ContextFactory distinction.
Eclipse context providers are plugins that extend the
org.eclipse.higgins.context extension point AND are required to implement
the IContextFactory interface. 

We are proposing to split them up conceptually. There seem to be two
benefits of doing so:

1) IdAS users can, if they choose to, distinguish between different
"engines" that might provide access to the same Context(s). This is NOT
provided by the current architecture.

2) Java implementations of IdAS can use the java.security framework classes 

Would you agree?

> 
> 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. 

Yes. And I've updated the "Relationship between Context Providers..."
section here: http://spwiki.editme.com/ContextProvider again just now to
reflect this point.


> 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.

If, by "users" you mean consumers of the IdAS API, then I'd say yes, these
users should be able to see and manage the "vendor-oriented" view of
providers.

If, by "users" you mean human users of apps like HBX and the i-card broker,
then I'd say no. 

Not only that but to support some human user use cases we currently have a
missing layer of abstraction/indirection ABOVE the current
IdAS-Registry/EndPoint. I'm holding back my comments on this matter until we
have the IdAS (and on down) design work done.

> 
> (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
> >
> >
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev