I've been doing BCHS with my computer group people as a way of nominally doing web but it moreso being a bunch of cool little C exercises. To be fair, the B, H, and S all got substituted, and I've been looking slantways at the C. (netbsd, netbsd's bozohttpd, and I'm not at a scale or relationality to really want to engage in S). It's kind of fun. I never studied computers, but I guess this is what baby computer scientists fiddle with (mine do anyway). It does underscore some of the high level features of common lisp as compares to C. (eq 'foo (getf 'bar '(frob ulous bar foo)) > T But how with... strtok(3) of a strlcpy(3) of a QUERY_STRING getenv(3)? Something interesting to me is that this is almost totally missing from gopher. In gopher mole cgi, you would also access an item type 7 search string from the environ(7) of the cgi, but that doesn't seem intended to be like web GET parameters (sez me). Instead - and I think this is the future of networking - I read in a dream that the gopher has a 'please give me a 3270 terminal' item specifier. I guess this is something like the historical boxens smj gives us access to. I was sadly too young to experience this, even though I'm old enough now (after you learn lisp, you start aging in both directions for both better and worse). Tangentially, smj evidently also has lisp machine boxens. I should brush up on flavors, which was the lisp machine lisp object system. Changing the common lisp object system to be like flavors instead again was a dry example of utilising the metaobject protocol- that's pretty much all my context here. Alright, I have been rejuvinated by non-web topics. Back to considering web BCHS from the gopher. I guess the reference is those powerpoint presentations from BSD conferences around 2016, which I haven't really been through. I think that what, mariadb had been substituted back in with chameleon after being substituted out, and helper frameworks such as kcgi (I have no idea what kcgi is actually). Alright, kcgi is a very complete BSD ecosystem light weight (fast)cgi framework, and probably is the legacy of BCHS at this point. I liked the nakedness of BCHS, the feeling of answering an http request by just printing Response: 200 OK CRLF to standard out. Trying to reproduce that manually in different places, where it's meant to be the same, would be a catastrophe. On the other hand, the fairly explicit kcgi response while gaining crucial uniformity through abstraction feels like it loses something, by having an abstraction that is just as heavy as the thing itself.