| Re: [higgins-dev] Context Provider vs. Context Factory |
|
I totally agree with pulling the word "provider" out of the interfaces.
I'll play devil's advocate on the subject of the roles of a factory.
On #1, I imagined in most cases the open method passing the supplied DI (used as AuthN materials) to the ctor of the IContext instance being created. But I suppose the open method itself could do other things with it. Still, it seems like whatever it does, it does in order to create/open a context.
On #2 and #3, Factories do sometimes utilize singletons and object pools. This is somewhat related, but not exactly the same. Not sure if keeping track of open contexts warrants saying it's not a factory. I'd feel more comfortable arguing my point here if closeContext() were moved from here to IContext.
That said, I kind of agree -- it's more than a factory as it stands. I'm fine with IContextManager unless people think it's a good idea to tease the functionality apart (aka "b" below).
Jim
>>> Greg Byrd <gbyrd@xxxxxxxx> 7/27/06 7:40 AM >>> My concern with using the term "factory" is that the functionality associated with the IContextProvider interface (in the working draft: http://spwiki.editme.com/files/IdentityAttributeService/idas-methods-0707.doc) is larger than what I generally associate with a factory. (1) The open method evaluates the policy of the named Context against the supplied DigitalIdentity. (Is this correct? When Tom posited that "the Context Factory does not concern itself with the evaluation nor enforcement of policy," Paul agreed.) (2) The getContexts (or getOpenContexts) method implies that a factory keeps track of the Contexts that it has created, or can create, or for which it is somehow responsible. Most factory classes that I'm familiar with simply create the object and hand it over. (3) The closeContext method again implies some further connection with the Context after its creation. So I've reverted back to using ContextProvider to refer to this entity, because it seems like more than a factory. The problem is that "provider" is a loaded term that is generally associated with packaging/deployment. I propose that we do one of the following: (a) Keep the current assignment of duties of the current IContextProvider but rename it to something that conveys more than object creation, e.g., IContextManager. (b) Refactor the functionality of IContextProvider into creation (IContextFactory), access (IContext), and management (registry) of contexts. (Where does the resolution of a ContextRef to a Context object happen? Factory? Static method of Context class?) I further propose that there is no need to include the "provider" notion (in the sense of packaging/deployment) in the API. The factory/manager object has metadata that can be used to convey vendor, data formats, etc. There will be different Registry implementations for different platforms, and each implementation must specify the process for registering and incorporating new types of factory/manager. ...Greg _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |