Re: [gopher] gopher++ (gopher1) protocol
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
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/gopher-project
Reply to: