RE: [higgins-dev] Re: Getting started with IdAS?

["Tom Doman" <TDoman@xxxxxxxxxx>]

Marc,

To add to what Paul said regarding #2:

The "interim" solution was intended to accommodate more than just
JNDI or XML backed context provider configuration.  Those were the
only two choices when the castor generated code was produced.
Since then, that enumeration isn't even used by the other CPs we
started in Bandit that don't have an enum value like, for example,
the JavaScript CP.  They just make their own value there and check it
"manually" via the DOM node.  At any rate, that code is remaining
status quo while the redesign solution proceeds.

Regardless, I expect that what we get from the "redesigned" solution
will also leave each CP responsible for it's own configuration within the
framework provided by XRDS.  I assume there will always be
configuration elements unique to at least every backing store if not
every CP that implements their method of accessing a given backing
store.

The following reference has more detail on the current thinking for
the registry and CP configuration framework:
http://wiki.eclipse.org/index.php/IdAS_Registries_Proposal_2B

Tom

>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 3/12/2007 9:33 AM >>>
Marc wrote:
> 
> All,
> 
> Thanks again for the push in the right direction.  I think I'm
> starting to understand IdAS and Higgins.  I still have a few questions
> though based on observations:
> 
> 1.  IdAS - It appears to me (I may be stating the obvious here) that
> the IdAS is not so much a service in the sence that OpenLDAP/MySQL/...
> are services but instead its a collection of interfaces and a registry
> for interacting with backend sources that must be utilized by a higher
> level "service" to be useful.  Is this correct?

Yes. In an analogy to JDBC think of IdAS as managing a bunch of different
kinds of database drivers (context providers). A little different in
emphasis from JDBC is that IdAS expects the "drivers" to also map the
underlying data model (which might be relational, a directory, or anything
else) into the common Higgins data model. The upper components of Higgins
(especially the I-Card Managers) are an example of a higher level service
that consumes IdAS.

> 
> 2.  Configuration - Each CP is responsible for it's own configuration.
>  The only thing in "common" between context providers is that each one
> is passed a URI in order to point to a config.  I have read the Novell
> config schema and see that it it hard coded to work with either LDAP
> or XML based resources.  I also saw that it is likely to change.  Is
> there a "common configuration" subproject in the works or some type of
> "best practices" for configuration design?  If every CP has it's own
> config model I would think deployment of a complex IdAS based system
> could be interesting.

We're in the middle of a redesign of how all of that works. The current
scheme was put together as an interim solution. Where we're headed is that
the ContextId is truly a "name" and it is mapped by registries into what
provider to use, where its configuration data is, etc.


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev