RE: [higgins-dev] [IdAS] registered Contexts

["Mary Ruddy" <mary@xxxxxxxxxxxxxxxxx>]

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