[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [higgins-dev] [IdAS] registered Contexts
|
See *** inline
-----Original Message-----
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Greg Byrd
Sent: Tuesday, August 15, 2006 3:48 PM
To: Higgins (Trust Framework) Project developer discussions
Subject: Re: [higgins-dev] [IdAS] registered Contexts
Greg Byrd wrote in response to Jim Sermersheim
> #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.
*** yes some contexts could be very private like your example. Others,
like "my email analysis" context may not have an existence that is
private - all the people in "my group" may have such a tool, but I sure
don't want anyone else to look at it. For purposes of discovery
efficiency, "my group" we may not want to have lots of discoverable
contexts around that can't be opened if they are discovered. The public
vs. not public is important distinction. It should also be possible to
have an "invitation only" context that can be open by certain multiple
people, but is not publicly discoverable.
So I think there's a case to be made to separate creating and publishing
a Context.
*** yes, as some contexts will have a privacy policy or need to be
iterated on in other ways before they are published.
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.
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev