[gopher] Updated Gopher RFC

John Goerzen jgoerzen at complete.org
Wed May 9 18:08:25 UTC 2012


Just a couple of cents from someone that's been passively watching this 
discussion.  Feel free to ignore me ;-)

If we might use one word to describe Gopher, it is "simple."  Gopher+ 
somewhat violates this, and HTTP severely violates this.  MIME types 
have their uses, and the Web and email wouldn't work so well without 
them.  However, even after all these years, they still aren't dealt with 
quite right.  If you click on a file on a Web server named foo.zip and 
the Content-Type header says it's image/gif, what happens?  And what 
happens after you do File -> Save in your browser, then try to open it 
up later?  (Note: these two things are not normally the same!)

Proper mailcap and MIME type handling could of course be added to 
Gopher.  But I would ask: why?

I think instead of adding more types, we could remove types and 
simplify.  The would be:

  * Plain text (ASCII or UTF-8)
  * Binary data
  * HTML text (ASCII or UTF-8)
  * gopher directory
  * info pseudo-type
  * Media

The "media" type would simply be binary data with a hint to the UI to 
attempt to display it based on its extension.

There are existing item types in existing specs that all of the above 
map to.

Let the client use its own mailcap, or whatever, to decide what to do 
with media data.

-- John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/gopher-project/attachments/20120509/6e40b7ea/attachment.html>


More information about the Gopher-Project mailing list