Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] new IdASRegistry

Yes, I think you're right on #4.  I'm trying to remember why multiple context factories had to be able to create a given context especially in light of what you're pointing out.  The configuration of each could be wildly different and some indication of what configuration to use MUST be included in the ContextId.  That makes them 1 to 1, does it not?


>>> Greg Byrd <gbyrd@xxxxxxxx> 8/7/2007 12:59 PM >>>
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().


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. 

Back to the top