[gopher] Re: Fate of the Protocol (was Re: Gopherness)

[Roman Pavlov <webmaster@xxxxxxxxxx>]

Kyevan wrote:
> Are you offering to host a new list? Not everyone has the resources to 
> do so, you know. And of course you wouldn't want to use port 70 to serve 
> notgopher, that would be silly. The best idea seems to be to modify the 
> Gopher protocol in non-backwards-compatible ways (adding headers of some 
> sort to ever resource grab seems to be the big change every other desire 
> relies on) 

-- And what's the difference from HTTP then? One can easily use apache 
directory listings to get "gopher with headers".

Here's my opinion on this topic, sorry if I'm repeating someone:

First, it is really strange that people on gopher list are discussing 
not how to support the protocol, but how to replace it. I don't mind if 
someone develops a new protocol and will be running servers on another 
port, but who actually needs it? How it will be promoted? Gopher atleast 
has a solid historical background and mentioned in /etc/services files 
all over the world. Currently, there are about, say, 1% of internet 
users who tried gopher (maybe still an exaggeration) - how much of them 
really need changing the protocol, ever thought about it?

Then, if we still want some changes, I wonder why everyone is so 
reluctant to use gopher+ which already has most of these improvements, 
like mime types support, implemented even better than in HTTP (user can 
choose which mime type to retrieve). However, mime types are technical 
slang, and item types is what average end user cares about: not gif, 
jpeg, png, but just image and that's all. In this perspective gopher0 is 
more user-friendly than gopher+ or HTTP.

As for myself, I feel happy without headers, mime types and even gopher+ 
(only using it in testing purposes with UMN gopherd). The only thing 
that needs improvement is UTF-8 support in clients. But this is not a 
protocol level problem.

> The real reason to do this is only to try to hit a middle ground between 
> http and gopher, really. HTTP is huge, unwieldy, and powerful, while 
> gopher is small, simple, and arguably less powerful. Trying to hit a 
> balance so we can handle some more complex things (like download 
> progress indicators and passing files to the right program on the client 
> side) while still keeping things simple enough that cheap, simple (or 
> old) hardware is still all you need to get the basic features out of it.
> 
> I suppose there's also the gopher+ route of adding extra fields (which 
> actually might be a better option), but is there any way to do that when 
> you send a magic string? It'd be really nice if a client didn't have to 
> know the item type for something before it requested it, but if we keep 
> serving on port 70, we obviously have to send that information in such a 
> way that it doesn't confuse old clients.
> 
> 
>