On Wed, 2008-02-13 at 13:32 -0600, Mike McGrath wrote:
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.
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?
If ldap doesn't fly, it doesn't fly.
my only question is how do you plan on doing the nss-integration for id
lookups? Continue using nss_db?
thanks
--
I only speak for me.