[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