[PATCH] Gate boolean protocol options on filename.

[João Taveira Araújo]

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
<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
>