[gopher] Updated Gopher RFC

[Kim Holviala]

On May 9, 2012, at 8:50 , Driedfruit wrote:

>> You're forgetting something: gopher is nothing but a straight through
>> unrestricted two-way TCP connection between a gopher CGI app and the
>> client. Why would you complicate things by encoding stuff and
>> resubmitting when you can just keep the connection open?
>> 
> 
> Please forgive my ignorance, that makes a lot of sense! But I'm still a
> bit confused, how would one implement such workflow? I understand the
> CGI keeping connection open and reading from stdin part, but not the
> client sending raw data part. Could you elaborate?

To my understanding (I stopped coding for living years ago) JavaScript these days has TCP sockets. So, the flow goes like this:

C: opes connection to server port 70
C: submits "/path/to/cgi?possible=params" + CRLF
S: runs /path/to/cgi passing params in ENV variables

That's it - after the CRLF the gopher server goes out of the way. JavaScript and the CGI are now free to talk to each other through the TCP socket - for the server (well, the CGI) it's just stdin/out, and for JavaScript it's a socket. Best of all it's 8bit clean (at least it is with Gophernicus - don't know about other servers but can't see why it wouldn't work).

Hell, to make it even more reliable Gophernicus actually execs itself out of the way, so it's really just a client (JS) and the server (CGI) talking to each other.

It's actually a hell of a lot better than what HTTP has, because the HTTP connection certainly isn't good for the above hack. You'd need another port open....


- Kim