> From: Howard Chu > Sent: Wednesday, May 14, 2014 6:41 PM > > Not at all. My position is still that we tried multiple alternatives and ruled > them out.
Yes, 10 odd years ago you looked at reloading a flat text configuration file and decided not to do it. And since not a single thing could have possibly changed in that 10 years, there's absolutely no reason to ever consider it again. After all, since signals and multithreaded programs were a bad combination 10 years ago, there's no way that signals and multithreaded programs could possibly work today, right? Just like 10 years ago there were no other options other than signals, such as UNIX sockets, to control a program externally. A decision made is a decision finalized, and pity the fool who might want to reconsider it, even if only as an abstract hypothetical. > > And you're still acting as if nobody has ever posted to the mailing list in > > favor of keeping the plaintext configuration, and of having the feature of > > dynamic reconfiguration from the plaintext configuration, which is just plain > > egocentric. > > No. That's experience too. Yes, you have plenty of experience at telling people who express the desire, need, or requirement for plaintext configuration that they don't really desire, need, or require plaintext configuration, that they are morons, have no basis for an opinion, have nothing to contribute to the discussion, clearly have no development skills, and perhaps should have never been born in the first place. > There's no excuse for ignorance when the links have already been posted and > everything is published on the www.openldap.org website. May I see a show of hands as to who has reviewed the entirety of the www.openldap.org website, including all of the mailing list threads, presentations, topics linked to, and FAQs? Didn't raise your hand? Please unsubscribe from the list immediately and stop pestering Howard with your uninformed and ignorant postings. You already have the framework for dynamic reconfiguration. If the guts are LDIF, more power to them. But there's nothing magic about feeding that framework LDIF. Given the ability to turn a plaintext slapd.conf into LDIF (which exists), the ability to take two LDIF files and generate a third LDIF file that turns the first into the second (which exists), it seems it's really not that much glue required to hook all that together and feed your dynamic reconfiguration framework the LDIF it wants based on the changes between two flat text configuration files. Disregarding the fact that you don't want to do it, disregarding the fact you don't want it done, and maybe even staying on track with the technical discussion and not diverging onto a tangent about how my great great great grandfather was too incompetent to shoe a horse, why exactly is it that such a design is infeasible, impracticable, and impossible to implement? Obviously you couldn't do this 10 years ago before you had the existing LDIF based reconfiguration framework, so saying you couldn't do this 10 years ago is not really a valid justification as to why it could not be done now...
