| Re: [higgins-dev] [IdAS] registered Contexts |
|
By "tree view" I was envisioning a sort of conceptual data model (well, it could be realized in some UI as well). The model being a two-tiered view where the top tier is the list of all factories and the second tier lists each context within that factory. Manipulations of that data can produce ContextRef-to-factory(ies) relationships, all contexts, etc. Assuming that was a good model, the registry could be implement in terms of it (rather than having a list of factories, a different list of contexts, and various tables mapping the different lists in useful ways. Just pre-implementation thoughts is all.
Jim >>> Greg Byrd <gbyrd@xxxxxxxx> 8/15/06 1:48 PM >>> 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. _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |