RE: [higgins-dev] IDAS context provider and endpoint APIs

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

Greg wrote:
> 
> 
> >
> > (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.

Agreed.
> 
> >
> > (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.  

Agreed.

> If I just create an IContext object, it doesn't have any metadata. 

Just to be sure, I thought that we had agreed that only providers can
instantiate IContext impls, and that there are no standalone, provider-free
context instances. 

> 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.

Yes.

<snip>
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.
> 

Agreed.