Extending ResolverStoredIDDataConnector

[Chad La Joie]

On Mon, Jun 11, 2012 at 1:32 PM, Tom Poage <tfpoage at ucdavis.edu> wrote:
> Understood. I didn't explain that I was thinking of a facility where one
> might be able to throw in a jar or two and 'wire up' (XML) a connector
> to a data source adhering to a well-defined data/repository interface.
> Something like this might assist in testing/adopting new data engines
> over time.

Well, there is no "well-defined data/repository interface" out there.
They're all different.  You can get close, I guess, if you pick a
family (e.g., key/value stores, graph databases, document stores) but
you can't really make one look like another.

> I'm not familiar enough with the IdP v3 design, Spring components, etc.
> to know if this is feasible, or makes sense even. The gist was to
> understand the degree of effort required to adapt a (non-relational)
> data store, such as MongoDB, to IdPv3 when available.

That's really hard to do.  You basically have to make a choice.
Either you have a content model that reflects the semantics of a given
component (that's what the IdP does now), or you have one that
reflects the semantics of the underlying programming language (that's
what the standard spring-bean schema is for).  I don't know which is
better.  Certainly there are people who have difficulties with the
current IdP config for various reasons.  I don't know if moving to the
native spring-bean format would help at all.  I suspect not.

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered