[PATCH] Gate boolean protocol options on filename.

Pendzik, Edward ependzik at harris.com
Thu Jul 28 21:25:13 CEST 2016

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.
Edward Pendzik :-)

-----Original Message-----
From: Bird-users [mailto:bird-users-bounces at network.cz] On Behalf Of João Taveira Araújo
Sent: Thursday, July 28, 2016 2:09 PM
To: Israel G. Lugo <israel.lugo at tecnico.ulisboa.pt>
Cc: bird-users at network.cz
Subject: Re: [PATCH] Gate boolean protocol options on filename.


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.

- j

On Tue, May 24, 2016 at 12:09 PM, Israel G. Lugo
<israel.lugo at tecnico.ulisboa.pt> 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
>> <israel.lugo at tecnico.ulisboa.pt> 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

More information about the Bird-users mailing list