OK, I'm trying to think this through. See if you agree with the
following:
(1) We want a Context, as identified by a particular ContextID, to be
this abstract notion of a particular set of identity information
(DigitalSubjects and their relationships).
(2) A particular context provider (via a particular ContextFactory)
implements this abstraction in a particular concrete way. The details
of this concrete implementation can differ, even if the abstract
Context is the same -- e.g., residents of Boston. (Even if the
underlying data store is LDAP, even with the same HOWL-based data
model, different CPs have different implementations of how that LDAP
directory is exposed via IdAS.)
(3) A particular ContextFactory needs some configuration information to
provide access to (open/create) a Context. The details of this
configuration information can be different from factory to factory,
depending on the implementation. At the very least, there's been no
attempt to standardize this information across CPs, has there?
(4) So, what goes in the XRDS file for a particular context? If the
info is factory-specific, then it doesn't make sense (perhaps) to allow
multiple factories to be named. If it's not factory-specific, then who
decide what configuration stuff is specified for a particular context,
and how is this published, so that someone else can write a CP that
consumes this information?
It seems to me that if we expect multiple ContextFactories to be able
to create a Context, then we need to standardize the language used to
describe how the Context is configured. I'm talking about really
detailed, mundane stuff -- like the names of settings, etc. The
factory has to consume this stuff in order to do createContext().
...Greg
Paul Trevithick wrote:
I’d
rather
not have the IdAS registry remember the binding. As long as IdAS
consumer
can, for a given ContextId, (a) get the list of potential factories and
(b) choose
which one it wishes to use, that should be good enough.
|
