Skip to Content.
Sympa Menu

comanage-dev - Re: [comanage-dev] COmanage COordinate: How Much Should It Weigh?

Subject: COmanage Developers List

List archive

Re: [comanage-dev] COmanage COordinate: How Much Should It Weigh?


Chronological Thread 
  • From: Dan Pritts <>
  • To: Benn Oshrin <>
  • Cc:
  • Subject: Re: [comanage-dev] COmanage COordinate: How Much Should It Weigh?
  • Date: Mon, 23 Aug 2010 12:17:04 -0400

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



Archive powered by MHonArc 2.6.16.

Top of Page