[PATCH] Gate boolean protocol options on filename.

[Israel G. Lugo]

On 07/28/2016 07:09 PM, João Taveira Araújo wrote:
> 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.
> 

Actually, no. I realize it's easier to just dismiss any confrontation by
yelling persecution, but you still haven't made any case as to the
utility of this feature, much less its sanity.

You mentioned some special "wildly different" use cases, which might
which even have shown this to be useful, but unfortunately you didn't
care to elaborate.

Instead, the reader is left to evaluate the merits of this idea based
solely on the claim that it is hard to "keep up with the syntax and
layout of a particular configuration".

Someone suggested using include files, which makes perfect sense. You
dismissed that with some vague hand waving about how if the included
file wasn't there, the config would be invalid. Totally ignoring the
suggestion, as the whole point was that you don't need any magically
disappearing files. You put your desired configuration in a file. Bird
reads the file. Done. Enabling a variable means "bla = 1", disabling it
means "bla = 0".

You further dismissed the suggestion you were given, going on some
tangent about having to parse configuration files. Nothing like that was
suggested or required.

I then mentioned that, if you're worried about files going missing when
they're not supposed to, then that kind of defeats the purpose of using
the presence of files to signal something.

Either you are in control of their presence, or you are not. If you
can't control their presence, game over. If you can, then you can rely
on them being there, and can use their content for something useful,
like configuring Bird.

Presumably you already know which features you want to enable, yes?
Great! Now just write these 2 lines of Python:

  for variable, value in my_variables:
    conffile.write("%s = %s" % (variable, value))

Want it in Bash? Ok:

  variable1=$(do_i_want_to_enable_A)
  variable2=$(do_i_want_to_enable_B)

  cat > conffile <<_EOF
  variable1 = $variable1
  variable2 = $variable2
  _EOF

You don't have to parse anything. The config file is a generated file.
You overwrite it with your (correct) version of the truth. You can even
include a warning header if you want to.



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

-- 
Israel G. Lugo
Núcleo de Redes e Comunicações
Direção de Serviços de Informática
Instituto Superior Técnico

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20160728/b62d7c41/attachment.asc>