COmanage Developers List

[Benn Oshrin <>]

I suspect implementing a stand-alone core with no external dependencies 
(other than perhaps a web server and a database server) will end up 
being the starting point, with the ability subsequently added to replace 
components as appropriate (Grouper, LDAP, etc.)

Though it's possible some functionality will be significantly simplified 
by having a cached set of data in the database even when external 
components are used...

-Benn-

On 8/23/10 12:17 PM, Dan Pritts wrote:
> It seems obvious that the DIY people will want lightweight and pretty
> likely that a big provider will want configurable.  So maybe this really
> comes down to "who is the audience."
>
>
> that said, there are lots and lots of apps out there that need an SQL
> db nowadays.
>
> the person running a DIY CO will probably be some grad student who's
> done a little LAMP work, so an SQL database will be more familiar than
> an ldap server.  And personally, having done plenty of both, i'd rather
> deal with mysql than openldap any day.
>
> In the heavyweight world you end up needing an LDAP interface anyway,
> whether it is provisioning ldap from sql, or a sql backend for ldap.
> (of course ldap general wisdom is that an sql db is not a good backend
> for ldap :)
>
> In either case, though, I think that good software development can hide
> the complexity of LDAP from the administrator, probably more than will
> be possible with an LDAP-centric approach.  It's just a matter of coding
> it up, right?
>
>
>
>
> On Mon, Aug 23, 2010 at 11:18:37AM -0400, Benn Oshrin wrote:
> > I'd be interested in some feedback or discussion about two different
> > models for the implementation of COordinate (the backend
> > middleware-esque engine).
> >
> > The lighter weight approach is very much similar to the existing demo,
> > with almost all data stored in third-party applications such as LDAP,
> > Grouper, etc.  The advantages of this approach include faster
> > implementation and no need for a SQL Server.
> >
> > The heavier weight approach starts to look a little more like a
> > traditional institutional identity management system, including an
> > underlying SQL database for most or all data.  The advantages of this
> > approach include abstraction away from specific technologies, as well as
> > easier integration for more sophisticated needs (such as reporting servers).
> >
> > A third model would be a hybrid or pluggable approach, but for purposes
> > of this thread I think it makes sense to focus on the two ends of the
> > spectrum.
> >
> > To the extent possible, I'd like to consider these options in the
> > context of the requirements of the entities likely to run this software,
> > including DIY COs such as LIGO and CaaS providers such as Penn State for
> > ESWN.
> >
> > Thoughts?
> >
> > -Benn-
>
>
> danno
> --
> Dan Pritts, Sr. Systems Engineer
> Internet2
> office: +1-734-352-4953 | mobile: +1-734-834-7224