[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] [IdAS] registered Contexts
|
Jim Sermersheim wrote:
#1 is an area where either I don't understand the use cases, or I'm
afraid we're making up stuff that we might not need.
At the last F2F, we had a conversation about a client who just cares
about Contexts, not about ContextFactories. Now, if that client already
knows the URI of the Context it wants, then it can simply use the
proposed getContextFactory(ContextRef) on a service to determine if
there's some Factory that might be able to open that Context.
If there's a need for IContextFactory.getContexts, then I believe
there's a similar need for IdASRegistry.getContexts, for the client that
doesn't care about Factories. I'm not sure why a client would want to
know this -- perhaps it's been told about an IdAS service where it can
find attributes, but it doesn't know the URI of a particular Context.
It can ask for a list, and then ask for the metadata for ones that look
interesting, and then try to open them, etc. In other words, this
supports Context discovery.
When I first started on this project, I had the view of a Context as
something that I could create for myself, populating it with
DigitalSubjects that I care about. I might not want such a Context to
be advertised to the world, even if no one else can open it. (Example:
"Greg's Drug Dealers.") I don't know if this is important or not, but
that was my motivation for distinguishing between public (registered)
Contexts and others. I can mitigate this by having a privacy policy
associated with the Context, but there's a period of vulnerability
between the create and the setPolicy.
So I think there's a case to be made to separate creating and publishing
a Context. Note that I have the same concern with
ContextFactory.getContexts, which I've never been quite comfortable with.
I understand the need to have something which represents a set of
IContextFactory instances. This would be used by the IdAS consumer to
enumerate all available factories. But beyond that, my gut feel says
one must visit the factories to enumerate things like: existing
contexts and potential contexts.
The IdASRegistry is your factory container. Its getContextFactories
method returns a (filtered) list of factories. If we add a
getContextFactories(ContextRef) method, then we can replace a sequence
of calls to the service (to find a Factory that can create a particular
Context) with just one call.
Then if there is a need to prime the pump, we could have a
bootstrapper class for that -- it would likely be config/policy-driven.
We currently have two configuration options for factories -- the
java.security.Provider method, and the Eclipse plug-in method. These
are built-in to the IdASRegistry code that I have written. Factories
can also be registered dynamically. I'd like to see an equivalent means
to register Contexts via configuration -- I hadn't design that yet,
because I had the feeling that it might be provider-specific.
I suppose what I'm thinking of as a context factory container could be
used by an IdASRegistry to produce a tree-view of factory instances
and their context instances. Further, I suppose someone might want
this IdASRegistry to be able to produce an enumeration of all context
instances (and maybe even distinguish between open and closed contexts).
So after going the log way around, I guess my opinion is that contexts
are not registered -- factories are. And IdASRegistry.getContexts
would be implemented by using some factory container to enumerate the
facotries, and then calling IContextFactory.getContexts on each.
Yes, I considered having the IdASRegistry simply call getContexts on all
the registered factories. I don't have a problem with this, if that's
the semantics that we want. (Not sure what you mean by "tree-view".)
<a bit off topic> The factory container (even if it's just an aspect
of IdASRegistry) should provide the ability to
auto-register/instantiate factories by virtue of them being present in
some configured directory.
See above -- Provider and plug-ins.
