| Re: [higgins-dev] [IdAS] registered Contexts |
|
#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.
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.
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.
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.
<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.
Jim
>>> "Tom Doman" <TDoman@xxxxxxxxxx> 8/15/06 9:14 AM >>> (1) What are the use cases you guys have come up with for the getContexts API? Seems like those will dictate the answer to your questions. Without being sure of the targeted use cases, I could see a case for each "or" and possibly a hybrid. (2) Sounds good to me. Tom >>> Greg Byrd <gbyrd@xxxxxxxx> 8/15/2006 8:40 AM >>> For the IdASRegistry, we have methods for registering and browsing both ContextFactories and Contexts. I'd like to explore what it means to register a Context, and what it means for a client to "get" a Context from the service. (1) Should the set of registered Contexts (i.e., returned by IdASRegistry::getContexts) be the ones that have been created by some Factory? To "prime the pump", we can have Factories create (but not open) some set of pre-configured Contexts, so that our brand new IdAS service has some registered Contexts to offer. Or should there be a specific set of registered Contexts -- those that the Factories specifically want to advertise to the outside world, rather than just any old Context that some client has managed to create/open? (2) We currently have a getContexts method (with a filter) that returns a set of URI's. Given a particular URI, the client will have to go through the set of Factories and call canCreate to find a Factory that can potentially create this Context. I propose we add a new getContextFactories(ContextRef) method to IdASFactories to make this simpler -- it returns Iterable<IContextFactory> that contains all Factories for which canCreate(ContextRef) is true. (Note: The current getContextFactories takes a filter, which I assume is the same filter as in the rest of the API, which means that it searches through attributes and metadata. My proposal is to add an additional method, not to remove or change the exisiting one.) ...Greg _______________________________________________ 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 |