On Sun, Sep 25, 2022 at 08:18:10PM +0200, Omar Polo wrote:
> On 2022/09/25 18:46:50 +0200, Stefan Sperling <stsp@stsp.name> wrote:
> > On Sun, Sep 25, 2022 at 06:38:12PM +0200, Omar Polo wrote:
> > > gotwebd' parse.y is derived from the "usual" parse.y, yet it doesn't
> > > have `include's nor the macro syntax, yet it has -D.  Don't know if it
> > > was a deliberate decision, but I personally like having the include
> > > and variables available.  (i've also took the liberty to rename
> > > newfile/closefile to pushfile/popfile to be closer to the other
> > > parse.y files.)
> > > 
> > > the manpage wording is stolen from smtpd.conf, vm.conf and httd.conf.
> > > 
> > > ok?
> > 
> > I suspect the lack of variables is just an oversight.
> > We definitely want those.
> > 
> > Regarding include, it adds some complexity which can sometimes backfire.
> > E.g. what happens if an included file overrides a variable used by
> > the outer file before and after the inner file gets included?
> 
> every time you use a variable the last assigned value is used.
> `include' in parse.y files is very, very similar to CPP' #include, so
> in yuor example in the outer file you'll see the value defined in the
> previously included file.  at least for me, it's expected behaviour.

So including files could indeed be problematic in cases where people
edit different files and don't check what the other file is doing.
Having just one file makes it much easier to spot mistakes in the config.

> > Are we really sure we need this for gotwebd? What is your use case?
> 
> to be fair i don't think i'll use variables or include files anytime
> soon, just as i'm not using fancy `listen on': my setup is pretty
> standard and could even work without a config file at all for the most
> part.
> 
> However, I see some value in it.  It could help for example to have a
> local config file while sync'inc the main gotwebd.conf across several
> machines for example.  Most of the justification however is "because
> vmd, smtpd, httpd, ... allow this."  I won't push for `include' if we
> don't want it (at least initially) tho.

I think it makes more sense to wait with adding the include feature
until we see a real need for it. Someone might eventually ask for it
and present a case, and then we can easily add it.
To me this seems like one of those features that look simple but may
have consequences nobody saw ahead of time, leading to problems down
the road which would not exist if the concepts had been kept simple.