Thank you for responding :)

> It could be useful in a long run, but I wonder if we need to formalize
> the API as srfi at this point.  We can start from a portable library and
> use it in many projects on multiple Scheme implementations until it
> become mature, to see how it fits well in Scheme universe.   It's not
> tool late to make a srfi after seeing the success of such
> library---after all, if we have one de-facto library, there's no need to
> agree on API among multiple implementations.
>
> If we find a lower-level abstraction required to write a portable
> middleware along the way, then we can make srfi for that specific area.

A portable web server implementation would definitely be a great thing
to have in its own right, but the main allure of the interface is that
it's extremely generic.

For example, CGI scripts just read a from standard input and write
response to standard output. HTTP request headers are pre-parsed into
environment variables. If Scheme is started as a CGI subprocess from
Apache or the like, the required HTTP library would be vastly simpler
than a full-blown web server.

Likewise, a Scheme embedded in a C/C++ program could opt to rely on a
high-throughput web server written in C/C++, with a C->Scheme binding
that supplies the request handler abstraction directly.

Another Scheme could opt to take a middle ground and do the HTTP
protocol parsing in C code that comes from a parser generator. (IIRC
Mongrel did this for Ruby, relying on a C parser generated by Ragel.)
But then do all the sockets and higher-level handling in Scheme.

It's due to this plethora of feasible implementation strategies that I
thought a SRFI specifying only the main abstraction would be useful.
Since the abstraction is so simple (if we focus on serial HTTP and
ignore future parallel developments) it would also be fairly
future-proof. However, I fully agree that we should try it with a few
implementations before setting it in stone. Preferably implementations
using different approaches as above.

Do you know what would be the most advanced existing Scheme work in this
area (barring Racket's interface, which we should also study and take
into consideration)?

Would it be good to gather everyone interested in this and develop a
draft spec on GitHub? Once it's in reasonably good shape, we can submit
it into the formal SRFI process.

> Or, do you already have an existing library in your mind to start with?
> Then I'll port it to Gauche and see how it goes!

I don't know of anything in pure Scheme. I have used the de-facto
standard abstractions in Go, Ruby, Python, Racket and Clojure.