| [higgins-dev] [IdAS] contexts visible via Endpoint |
At the last Higgings face-to-face, we decided that the user of an IdASEndpoint may be interested in what Contexts are available, regardless of the Context Providers that source them. So, we added the getContexts method (including the TBD filter string).
Since not all Providers would want to publicize all of their Contexts, we also included the notion of "registering" Contexts with the Endpoint. Only registered Contexts would be returned via the IdASEndpoint:getContexts method. So we also have registerContext and removeContext (which should maybe be "unregisterContext"). However, we need to coordinate the Context registration process between the Endpoint and the Provider. I can think of a few alternatives:
(a) The Endpoint calls getRegisteredContexts for each Provider. The Provider "knows" which of its Contexts should be made public, and it returns that list to the Endpoint. This also allows the Endpoint to map Contexts to Providers, which is helpful/required for the Endpoint's getContextMetadata method.
(b) When the Provider is constructed, it calls registerContext on the Endpoint for all of the public Contexts. This requires the Provider to have a pointer to the Endpoint object. Also, if the Endpoint needs to map Contexts to providers, the registerContext call must also include the Provider as a parameter.
(c) The Endpoint calls getContexts for each Provider, with a filter that specifies a well-known (i.e., Higgins-defined) metadata type which indicates whether the Context is public or not. (This means we have to trust the Endpoint to only ask for the right set of Contexts.)
(d) All of this could be policy-driven, at the Provider, or the Context, or both. The getContexts call to the Endpoint could be passed on, along with the identity of the caller, to each Provider, which in turn decides whether to return a particular Context to this requester.
In cases (a), (b), and (c), the Provider must also be able to register a new Context when it is created. In case (d), the Endpoint only "pulls" Context info when it is asked, so there is no reason for the register/unregister methods at all.
Are there other alternatives? Can/should we settle on one? The policy-driven approach is the most flexible, because it avoids the either-or public/private decision. But that also means that we should think about policies sooner, rather than later.
Of the other alternatives, I lean towards (b), because it uses the same method for initial and new Contexts, and it puts the Provider in the driver's seat. We would have to add another method to IContextProvider, so that the Endpoint can pass itself to the Provider.
...Greg