[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: dropping back-ldbm (was: commit: ldap/servers/slapd connection.c)
--On Friday, January 21, 2005 12:48 AM +0100 Pierangelo Masarati
<ando@sys-net.it> wrote:
Quanah Gibson-Mount wrote:
We may need a fallback solution
in case any issue (even deployment-specific) occurs.
I'm not sure what you mean here. Why is a fallback solution needed?
If by any means I can't get back-bdb behaving as expected at a customer's
site (it happened, and may happen again) I want to be able to chabge
"bdb" (or "hdb") into "ldbm", run slapadd and go home and try to fix the
installation/configuration. I don't want to have to reinstall the 2.0.X
rpms that come with AS3.0. It's a sort of a psychological backup that
customers adore. They know back-ldbm worked for years, and they heard
that back-bdb is hard to configure, set up and tune.
Okay, this really misses the point of what I just wrote.
First, something being broken in the backend logic could happen with any DB
(i.e., this thread got started because of a bad commit to ldbm). So just
because this worked for you in this case, doesn't mean it'll work in future
cases.
Second, I suffered several years of an ldbm based directory. The comfort
your customers feel is illusionary, and sadly like many things
psychological, it is all in their head. :P
Third, how much time is spent just keeping LDBM working, when the real
future is in other backends? It is like hiring someone to keep updating a
mainframe that can be used, but isn't, just in case you decide to use it
again. It eats up time, and time is money, opensource software or not.
Finally, none of this addresses the question as to when we evaluate things
for retirement.
One answer is, of course, when they are no longer maintained, and I can see
that happening for some features. However, with other things, they can be
maintained indefinitely (possibly like LDBM), but they just become a major
time sink, and everything gets more complex when dealing with it as new
features (say the implementation of the disclose code) are added to
something that wasn't designed to have these types of things easily
integrated in.
So maybe 2.3 isn't the release to drop LDBM. But what IS that release?
2.4? 3.1? I think the argument of needing the fallback solution is faulty,
because it can be used to keep something that should be axed forever.
And you could of course, install OL 2.2 RPM's or whatever, if you really
wanted to get them set up on LDBM with OL.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin