Paul B. Henson wrote:
From: Howard Chu Sent: Tuesday, May 13, 2014 3:56 PM
It was the only sane choice, and as you are not a developer and were not participating in the design discussions back in 2002-2003 you're not in any position to comment or critique on it. And judging from your commentary, you're not qualified to offer an opinion.
I see, you're going to go with the "your opinion differs from mine;
therefore, you are clearly not qualified to have an opinion" argument?
No, I'm going with the "where were you with your bright ideas when we needed help designing and implementing this?" argument. You're not a developer and clearly unable to write code that behaves as you suggest. Nor are you anywhere volunteering to sponsor such work.
Meanwhile, you have no concept of the programming constraints that led to the decisions we made, nor sufficient background to appreciate their significance.
Your opinion is worthless noise.
As a systems administrator who has been managing large-scale distributed
systems since the mid-90s, I think I do actually have the qualifications to have an opinion on configuration management.
It's all well and fine for you to say "sure they could have kept the flat text file" but we would have had to invent a remote administration protocol and all of its required security mechanisms.
Really? It's amazing then how other enterprise scale software packages such
as Apache httpd managed to survive using flat text file configuration models without inventing secure remote administration protocols for deploying that configuration.
Again, you're mixing up two things – how configuration is processed, and how
configuration is delivered. You are tightly coupling two things that do not need to be coupled, basically decreeing by fiat that only that configuration which arrives over the LDAP protocol may be dynamically placed into effect. If someone already has a secure way of delivering flat text file configuration updates, too bad, they don't get to be dynamically applied. Not because it's impossible to reload a configuration file and apply the changes, but because you don't want to do it.
stupid, when we already have highly evolved protocol, data model, and security mechanisms in place. Keep in mind that none of puppet/chef/cfengine/what-have-you existed or were in common use in that timeframe.
Perhaps, but in the late 90s, before this design discussion that I didn't
participate in even took place, I already had secure mechanisms for delivering configuration files to large distributed networks of systems.
Your examples are irrelevant and not applicable.
I've been writing server code since the 1980s. Yes, it was common practice back in the day to allow manual rewriting of config files and sending a server a SIGHUP to tell it to reread its config. But hey moron, that didn't work with threaded programs. Signal handling wreaked havoc with the threading implementations of the day. If you were a developer you might be aware of this fact. But you're not, and you have no valid basis for any opinion of how the code should have been implemented.
Nor can you sanely reload an entire slapd.conf file without doing a bunch of redundant parsing, to skip over the parts that didn't change. It's a lot of work simply to find the parts that didn't change, unless you invent a network protocol that lets you send deltas. But oh wait, we already have a protocol with that - we can use the LDAPModify operation.
I don't think I ever claimed it wouldn't involve some additional code, some
additional work, to allow dynamic reconfiguration from rereading a flat text configuration; I simply claimed it is possible. And "redundant" or not, parsing a configuration file into a configuration structure is hardly intractable, nor is running through the existing in-place configuration and comparing it to the new configuration just loaded in determining the differences.
How kind of you to volunteer someone else to go to all the trouble of donating the additional work required to implement a non-viable mechanism. That's not how open source development works. If you want a feature, you either write it or you sponsor its development. You're clearly not qualified to do the work yourself. In this particular case, it's pointless anyway because the feature you're requesting, to make slapd behave like every other historical Unix daemon, is a non-starter.