On Sat, Jun 20, 2020 at 10:27:51AM +0200, Stefan Sperling wrote:
> On Fri, Jun 19, 2020 at 10:34:39AM -0600, Tracey Emery wrote:
> > This also paves the way for centralized parsing for gotweb and gotd.
> 
> Sorry about rewinding the discussion, but reading your new diff it
> occurred to me that having just one parser might not be a good idea.
> 

No apologies. That's how discussions are made, and this definitely
needed more discussion.

> I see a trade-off we have to make between code duplication for parsing
> config files, and re-usability of our library APIs.
> 
> Configuration files are by definition application-specific. The library
> should not actually need to know where configuration information comes from.
> All required information should be passed in via function parameters.
> 
> The got_config.h you're adding embeds knowledge about gotweb in files
> that live in the global include/ directory. These files declare the
> library APIs which are available to all applications.
> Why would gotweb's configuration variables need to be known to gotd,
> got, or tog? Or any other application that people could come up with?
> 

I had been thinking about certain gotweb problems, so making everything
known to gotd was a step in fixing some problems. But, I'll discuss that
more later. It's a bad idea, and I changed my mind.

> When someone writes an application using the library, they would reasonably
> expect that they can use this library without first adding new information
> about their application to files in the library's include/ directory in
> order to parse their application's configuration file.
> 
> If we don't unify the parser, one obvious downside is we have multiple parse.y
> files. Is that bad? I don't know how much of a burden they are to maintain.
> 
> Have you already thought about this?

It's not terrible to maintain over 3 or 4 parse.y files. Is it a lot of
code duplication? Yes. Is there room for adding multiple bugs to
multiple files? Yes.

However, I think you're right, and I'm abandoning these diffs. I'll roll
the first diff back to work strictly with got. It makes sense to keep
these things separated. Developers will just need to remember that if a
change makes sense to that parse.y to ask themselves if it makes sense
in the others.

We have discussed having gotd give gotweb a socket to pass fds around. I
started wondering what other problems gotd could solve in this regard.
Could the problem of testing be solved? Then I thought a lot about other
design changes.

After reading this email, I don't think gotd should be doing any of
those things for gotweb. It needs to take care of it's own things and
not worry about gotweb. This made me think that gotwebd needs to exists.

I think that gotwebd could be built to deal with regression tests and
act as something like a RESTful API for a new gotweb frontend.

So, yes, it makes sense to not go the direction of these two diffs. Now,
I know it's a segway, but, thoughts on the gotwebd idea?
-- 

Tracey Emery