Welp, I've failed.
So a year ago we talked back and forth about what to do for FAS2. We've
spent a LOT of time on getting an easy front end to an LDAP back end. It
was a reasonably heated debate whether or not to use LDAP or postgres for
the back end. I was heavily in favor of LDAP for 3rd party support.
Well, over time its become clear that LDAP is just not very good at doing
groups as we want it to do. We need to have people self-add themselves to
groups, track when they were added, who added them. People can have
different access levels in the group (unapproved, user, sponsor, admin).
LDAP is very geared towards what most people need (someone in charge of a
group and adding people to that group). In an open environment like ours,
we need the whole application process. Its not that LDAP is bad, just not
the right tool for the job.
At the same time, during this last year, we've seen a huge push towards
OpenID adaptation which is something we've always wanted on the front end.
Our turbogears apps have proved to work very well and creating an api to
work with FAS2 is very easy. In light of these things, the big benefit of
having ldap on the back end (3rd party apps) seems less grand and less of
a win.
We've been working on FAS2 for almost a year now, and with the deadline
looming the FAS2 dev's (me and ricky) talked about the best way to move
forward. We've decided to stick with an rdms. Fortunately it shouldn't
be too difficult for us.
We had been basing our application on fedora-ds, during the last year
we've seen great changes in this application and how its packaged. This has
made it less stable/desirable as a back end. All signs point to using
postgres on the back end as being both the easier choice and the more
reliable choice based on what we've seen.
I don't like to make decisions like this in a vacuum but time is tight and
I really want to make this deadline.
Thoughts? Comments? Concerns?
-Mike