Re: [gopher] Updated Gopher RFC
On 2012-05-09, Kim Holviala wrote:
> About the mime types and handling of them - I don't really see why
> gopher should have mimetypes.
>
> If we'll take the simplest possible gopher client - say something on a
> Tandy T100 (I've got one on WiFi, haven't gotten around coding a
> gopher client yet) - there's just no way to *ever* show anything else
> than plain text and menus. No need for mime, or types other than the
> basic ones.
>
> If we'll step up a little and take a generic Unix console from mid
> 90's (early Linux etc) then we'll probably run our gopher client as a
> normal console program (Lynx/UMN gopher etc). The way we handle HTML,
> audio, video, images etc is to launch an external viewer. With an
> external viewer we'll only have to know about the basic type of the
> file; if it's an image we'll probably launch XV, Ghostscript for
> PS/PDF, XMMS for all audio, video we can forget etc etc. There's
> really no need for mime as the applications themselves will do content
> detection *anyway*, and the gopher client itseself couldn't care less.
Indeed -- what the gopher client is more concerned about is what kind of
content is the menu entry, as in what should it do with the resource
(show an image, render a document, play a movie).
There will be incompatibilities and mime types may help solving these,
if the client wants to try that.
What if a revised RFC
- Keeps the initial items, along with the few more that were widely
adopted for specific formats (e.g. pdf and png)
- Add new purpose-based item types (image, movie, document, ...) to be
used with a new mime-type field
- Split the "unallocated blocks" of item types in purpose-based regions
(e.g. new types in the range a-j should be used for images, j-o for
movies)
I'm unsure whether the last suggestion helps with anything at all, but I
guess clients which could support the generic item types would also be
interested in trying to render, say, unrecognized types in the image
types "block".
mime-types would be optional, although possibly encouraged for the
purpose-based item-types; for the initial items, these should be
discouraged, at least when a specific format was established in the
original RFC.
I get the feeling that having both generic types with mime *and*
splitting the unallocated types by purpose is a bit redundant, but OTOH
those different ideas could end fulfilling different purposes: the
unallocated types could be used for new formats which become commonplace
(such as what happened with png and JPEG), and the mime-type for these
less-common formats (for example, DeJaVU, unless the gopherspace uses
DeJaVU as much as I do).
The question is whether this hurts the simplicity of gopher. At least
this approach would not require more round-trips.
> Yes, I'm conveniently forgetting about /etc/mailcap which uses mime -
> hands up who actually edited their mailcap to actually *work*?
>
> Stepping up to modern days, browsers these days don't care about mime,
> at all. It's a blessing and a curse at the same time (mostly because
> IE does a different thing than Firefox which almost but not quite
> works like Webkit). Again, no need for mime since *everything* is
> content-sniffed... Again, hands up those who know what mimetype your
> webserver uses for CSS (most webservers get it wrong and it still
> manages to work).
--
Nuno J. Silva (aka njsg)
gopher://sdf-eu.org/1/users/njsg
http://njsg.sdf-eu.org/
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
Reply to: