[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] IDAS context provider and endpoint APIs
|
(1) IContextProvider needs a getIdentifier method. We will want to list
registered providers in a human-readable way.
<raj> Would getName() be sufficient? Or would that identifier be used
for any other purpose (e.g., metadata, policy, etc)... wondering about
use case for getIdentifier (for that matter.. getUniqueIdentifier()).
</raj>
Yes, getName is probably better, since we don't need a URI here. Since
"identifier" means URI/XRI for a Context, we don't want to confuse things.
(2) In order to implement the IIdASEndpoint getContextMetadata method,
there needs to be a way to connect a context URI with a provider.
<raj> hmm... interesting implication or assumption here. Does all of
ContextMetadata depend on ContextProvider? Is there is no metadata
that can be used independent of a provider? </raj>
We can either define a specific format for the ContextRef that does
this,
or we can rely on the context registration process to map contexts to
providers. (I think that providers should explicitly register the
contexts that they want to be publicly accessible via the endpoint.) If
the latter, we need to change registerContext(URI) to
registerContext(URI, provider).
<raj> yea.. if contexts cannot exist without a provider (which is true
to access the info), then you are right.
Is Context to Provider a one to one mapping or would IdAS framework
be capable of aggregating providers for a given context?This is
related to the discussions we had at the F2F. I thought the initial
'implementation' related design agreement was that we will keep it
simple wrt providers to do aggregation. But i think IdAS impl needs to
provide the support for aggregating, federating,..providers based on
context requests. ofcourse.. above updated api can be used (called
more than once) to associate multiple providers for the same
contextref/uri.</raj>
So far, the only way to instantiate a Context is to open it via the
provider. I do think that the provider (or "a" provider) must be
involved in getting the metadata. If I just create an IContext object,
it doesn't have any metadata. I think that accessing the metadata
requires "going" where the data resides, namely in the provider.
I think it's OK to aggregate providers. I don't think it's necessarily
a one-to-one mapping. There may be multiple providers that can source
the same Context.
(3) To support (2), do we want an "initialize" method for
IContextProvider, or some sort of "registerContexts"? We need to
somehow pass the endpoint object to the provider, so that it can perform
the registration.
<raj>
Depends on if the provider need to self-register?
Let me think thru this..
(a) I think provider's registration to Contexts cannot be in
initialize(). As providers can be initialized and reused across
multiple contexts.
(b) If we have, registerToContext like method on providers, question
is .. who is going to invoke it? IdASEndPoint or someone else?
There are atleast two use cases i can think of
(i) IdASEndpoint based on its configuration.. registers the
provider. In which case, method in #2 above (registryContext) on the
IdASEndpoint would take care of it.
(ii) Someone else.. (outside of IdASEndpoint), would register a
provider and bind it to a particular Context, in a particular
IdASEndpoint. In that case, instead of asking the provider to self
register, it can as well ask the IdASEndpoint to register that provider.
would that work?
</raj>
I wasn't thinking of "registerToContext", rather
"registerToIdASEndpoint." In other words, we said that the user of an
endpoint should be able to ask what Contexts are available via that
endpoint (regardless of provider). I believe that the provider should
control whether a particular Context should be part of that list.
That's why I want the provider to explicitly tell the endpoint (i.e.,
register) what Contexts should be presented to the public.
If that's not necessary, then the endpoint can simply do a
provider.getContexts when a new provider is registered, and it can list
all of the contexts.
(4) We need IContextProvider to have a getContextMetadata(URI) method,
because we can't convert a URI to an IContext without opening the
context -- <raj>yep.
btw.. wrt terminology, you dont need to 'open' a context to get
'metadata', right? Metadata should be accessible without 'opening' it.
When I say 'open', I am referring to the discussions about things like
'ldap bind' operation. The method may still be required .. but I am
trying to differentiate between instantiating a context (so that it
can be opened), vs opening a context. </raj>
so the endpoint can't call getMetadata on an IContext because
it doesn't have one. (Alternatively, we need another way to create an
IContext object, and we rely on state information to know whether it's
open or not.)
I agree, you shouldn't have to open a Context to see its metadata.
That's why we need a separate method. In the current API, the only way
we can get an IContext object is to open it. So, we either need a way
to get an object without opening it (and then we can look at the
metadata), or we need a way to ask for the metadata via a URI, so that
we don't need to open.
(5) Relevant to (4), I'd like to change all of the context-related
methods in IIdASEndpoint to use URIs instead of context objects.
...Greg
