[gopher] Re: Gopherness

["Jay Nemrow" <jnemrow@xxxxxxx>]

I would also be a bit concerned about backward-compatibility (as I
always am).  When we talk about changes like this, I suggest we call
the protocol created with modern changes something besides just
"Gopher".  Perhaps Goph08 or something like that.  Then you could say,
"hey, I run a Goph08 server" or "my client is both Gopher and Goph08
compatible."

Of course, I am thinking that the "Intelligence in the server" could
be used to allow for interesting "magic strings" to be sent to it from
Goph08 clients: "\fud\pug.jpg$G08" or something like that, indicating
that the client would like Goph08-type responses (in different
encodings for different languages).  There is no standard way,
however, for older servers to deal with a Goph08 magic string except
to fail on it and then the Goph08 client would need to fall back to
Gopher0 magic strings - messy (since Gopher really doesn't include a
standard error indication - it will return a text that says things
didn't work out) but doable.

If we do a version of Gopher which is basically new (adding UTF-8 or
MIME or whatever), I think we should ask for and get a new port
assignment for it.  If you wanted Goph08, send the request through a
Goph08 port number.  Gopher request continue to go through port 70.
Just have your server listen on two ports instead of one, using the
old idea that if you are using a different protocol (essentially), you
should use a different port.  (Crazy idea, I know.)  I guess this gets
back to an old point, which is that a modern version of Gopher is
essentially a new protocol and should be treated as such.  If you guys
want to change Gopher to "improve" it, it ceases to be Gopher.
"Updated" nostalgia is not nostalgia at all.

Jay

On Mon, Aug 4, 2008 at 10:19 AM, Kyevan <kyevan@xxxxxxxxxxx> wrote:
> What about older clients, though? Modern clients will probably handle
> UTF-8 at least well enough to not explode, but older clients might not.
> Generally, it seems safest to stick to the subset that is ASCII when
> reasonable, only using UTF-8 or such when it's actually needed. ... is a
> perfectly readable replacement for U+2026, even if it's not
> "typographically correct." On the other hand, if you're trying to post a
> text in, say, a mix of Arabic, and Klingon, go right ahead and use UTF-8.