On Fri, 2006-06-23 at 08:34 -0500, Mike McGrath wrote:
Aurelien Bompard wrote:
>> P.S. joe^, if you're around, I didn't mean to exclude you from this
>> process. We did miss you at today's meeting, and everyone who pitches
>> in is welcome :)
> I'm pitching in ! :)
> I read the log, but it's not totally clear to me which framwork will be used
> for the account system. Turbogears ? Cherrypy ? Pure Python/CGI ?
Some of us are still under the opinion that it should have an LDAP back
end. Any thoughts from the new joiners?
Were the advantages discussed on the sys-admin list? Could the pros and
cons be summarised?
Every time I look at LDAP I get confused whereas SQL was easy and
intuitive to pick up. So as someone who's potentially going to be
programing against it, I'd vote for staying with an SQL backend.
By the same token, I don't know much about LDAP because I've never done
anything useful with it as a backend. Is it easy to extend LDAP data?
Is it easy to program against? Can I write arbitrary queries?
About the only thing I've heard is that LDAP is:
1) lighter weight than an SQL db esp. when querying data.
2) has lots of admin tools.
In regards to 1:
- We're going to be running a lot of other tools out of SQL dbs. Does
this still make sense when we have to run an LDAP server as an addition
to our existing SQL servers?
- We'll be querying the data more frequently than adding or updating but
it isn't by any means static data. Contributers are constantly
requesting addition to new groups, being upgraded, having their requests
denied or approved, and so forth. At what amount of data churn does
LDAP stop being more efficient than an SQL database?
- What admin tools exist that we'll be able to run? There are admin
tools available for SQL db's that we aren't currently using either....
- Are the tools flexible enough to work with the extra data we're going
to want to associate with an account or are we going to end up writing
external programs to do the job whether they're in an SQL or LDAP