On 24-05-2016 19:36, João Taveira Araújo wrote: > Hi, > > On Tue, May 24, 2016 at 7:31 AM, Israel G. Lugo > <[email protected]> wrote: >> >> But that is still the case in your approach... The file being present >> dictates whether or not the configuration is valid (does what you want). > > If the file is not present, the disabled statement is off. In both > cases the configuration is correct.
You are referring to syntactic validity; I'm referring to semantic validity. A correct configuration for me is one in which the router does what I want it to do. >> In fact, for me your approach is more dangerous: in the "include" case, >> an accidentally deleted file will trigger an error (which you will >> notice and fix), but in your case it's impossible to tell whether a >> missing file is an error, or you really mean it. > > "Accidentally deleting a file" is about the same as "accidentally > putting the wrong value into a stanza". If you want to avoid exposure > to either case, you don't use either feature. Please note that the problem of disappearing files was brought up by you in your initial email: "the file must always be present otherwise the config is invalid". I merely noted that if you're in a situation where you have to worry about configuration files suddenly disappearing, then you will most definitely want the daemon to break and throw up when that happens. Not silently toggle a flag and change half your network. >> In my opinion, configuration error (in this case an accidentally deleted >> file) should break rather than silently malfunction. >> >> Put in other words, you now shifted the responsibility of configuring >> the service on the mere presence of files in specific places. That's not >> a very common practice... > > I value practicality over common practice, my use cases are wildly > different to most. Please cf the principle of least surprise. Nothing's stopping you from patching Bird to read binary-encoded prefixes from an inode's timestamps... and while that may seem very practical for some wildly different use case, it will still surprise the living sanity out of anyone unfortunate enough to be hired to manage such a system. > We've used that sort of include script in production for many years. > It's OK (and unavoidable if you want to have dynamically generated > prefix sets), but as an interface it's more complex and as an > abstraction it's less elegant. I would argue that this alteration is what adds complexity to the interface... As for elegance, I would ask about consistency. Why only boolean values? What if I want to specify a timeout value using the amount of files in a directory? Can I create 50 files to mean 50 seconds? Why use files? It could be the content of a symlink. Or the presence of a certain username. That way I can toggle the configuration just by logging in. Surely that must be practical for some wild use case too... Regards, -- Israel G. Lugo Núcleo de Redes e Comunicações Direção de Serviços de Informática Instituto Superior Técnico
signature.asc
Description: OpenPGP digital signature
