[gopher] Re: Item Type Suggestions

[Jason Nemrow <jnemrow@xxxxxxx>]

Yes, my first thought is that just adding mime to the end of the menu entit=
y would do the job simply and easily and, dare I say, gopherly.  What do ot=
her think of Mate's idea?

-----Original Message-----
From: "Mate Nagy" <k-zed@xxxxxxxxxx>
To: gopher@xxxxxxxxxxxx
Sent: 7/22/08 12:18 PM
Subject: [gopher] Re: Item Type Suggestions

> I think the convention set out in gopher+ is the better way to add the
> mime extension, as an added tab field after the ones established by
> RFC 1436.  All decently built gopher0 clients ignore anything on a
> menu entity line between the port number and the <crlf>, so this is
> where additional metadata (like mime types) logically could go without
> breaking older clients.
 +1
> If I am confused about what you all are talking about, I apologize,
> but it seems we are barking up the wrong tree with URLs.
 +1
> Also, if we are to deal with mime types at all, I am thinking that all
> of them must be put under the 9 item type, no matter what, just to
> keep old clients from breaking.  If you put a .doc file under the 0
> menu type, the old client wants to dump that to screen as text and you
> will see gibberish and probably crash things.  Everything that doesn't
> fit into the established types will have to be 9 item types, as far as
> I can see.
 +1 (although this one has been said before).

 About URLs: Someone has mentioned "relative links" in a previous mail -
that was strange enough in itself, since there is no such thing in
gopher. (Thus, it "cannot be broken"; and it especially cannot be broken
in the server, which would put the mime bits in there itself, most
probably after having generated the full selectors from all those
relative links the content generator user supplied.)

 I would support a variation where we'd write off gopher+ as the
complete failure it is, and just stick mime fields at the end of the
menu records.

 Let's not try to support the complete feature set of HTTP 1.1 in
gopher, it's not too well suited for that. We're in this for the
simplicity, right? I can however imagine that some gopher servers could
support HTTP on the same port (as some do already), and provide mime
types, continued downloads, encodings and whatnot that way. There might
be a "standard" way of mapping selectors to HTTP urls, and maybe a
"standard" way for the client to discover this capability in the server.
So in the end, you could click on the 50 meg PDF someone uploaded in
their infinite wisdom and see Overbite (or anything else) happily
continue (for the 13th time) to download the file.

 Or maybe we could drop the menu format and move to XML, ha ha.

Regards,
 Mate