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.
