Hello All, Personally I like the proposed "existence-of-a-file-is-a-Boolean" approach because of the exact reason That it was originally proposed: It simplifies, clarifies, and significantly easies integrating bird config and control into other applications. Thanks! Edward Pendzik :-)
-----Original Message----- From: Bird-users [mailto:[email protected]] On Behalf Of João Taveira Araújo Sent: Thursday, July 28, 2016 2:09 PM To: Israel G. Lugo <[email protected]> Cc: [email protected] Subject: Re: [PATCH] Gate boolean protocol options on filename. Hi, Any feedback on this? I didn't follow up with a reply because the argument presented against was a straw man fallacy followed by a slippery slope. I realize that I could very well encode a boolean in 134 characters as in the example provided, but would rather signal that through the presence of a file. Cheers, - j On Tue, May 24, 2016 at 12:09 PM, Israel G. Lugo <[email protected]> wrote: > > 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 >
