[gopher] gopher++ (gopher1) protocol

[Kim Holviala]

On 11.1.2010 10:52, Dennis Schulmeister wrote:

>> There were some pretty big mistakes in the document... I'll try to
>> find some time today to fix some of the most glaring bugs :-).
>
> Interesting thoughts. Two (Ok, three) things I noticed while reading:
>
> There needs to be a way the server can detect that the client doesn't
> want to send more data. Usually there's a blank line after the header
> fields indicating this.

... and that was the biggest mistake I had in the document. There were 
other glaring bugs too which I'll fix as well (like the requirement for 
a server to be able to convert html to text).

So yes, a gopher++ client sends an empty CRLF when it's done with the 
headers. A gopher++ server is required to read the gopher0 selector and 
wait for some predefined time for the extra headers (0.01 seconds?) and 
if the extra headers don't come it's expected to handle the request as 
gopher0.

> Visually impaired people usually use screen readers which read text out.
> So there's no need for the server to handle this, too. :)

That was just an example :-), besides the document said the server 
doesn't have to obey stupid requests like that...

> I think there should be a special request sent by the client in order to
> probe the server for its capabilities.

I thought about that but couldn't figure out a clean way to do it. Maybe 
the client could request a special selector (say, "server-status") which 
would then contain machine-readable information about the server. Even 
gopher0 servers could then provide server-status just by serving out a 
static text file.

I think I'll include server-status to the next revision of the document.

> You're requesting quite a lot on
> the server side and a specific implementation might not be able to do it
> all. e.g. I got my gopher server running on a small host with only few
> available resources (by today's standards). It would take several
> minutes to transcode a bigger pdf document into png images.

If the server cannot transcode the resource then the resource is sent as 
is. This sounds a bit rough until you realize that it's exactly what 
gopher0 does -> no transcoding = fallback to gopher0. A client is 
expected to check that it's getting what it was asking without 
segfaulting (another thing that was missing from the doc).

My current server is a beefy virtual machine on a quad-xeon and lots of 
memory, but one of these days I'll set up my SGI O2 with IRIX/6.5 and 
move everything over to that machine so I'm not really counting on raw 
CPU power.

But, to be honest my primary motivation in the spec *was* to keep the 
client as simple as possible and move all possible CPU-bound tasks to 
the server. It's always easier to add server capacity than it is to add 
client capacity (since admins providing the content have no control over 
clients).



- Kim