[gopher] Re: Item Type Suggestions
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Cameron Kaiser wrote:
>> Does this mean that we have to look up the mime-type for each file? What if
>> you don't know it? Also, wouldn't this make it harder to give links to other
>> people? I'm not really at peace with these things - mime-types and all that
>> just aren't my cup of tea.
> It would make them longer, yes. However, the idea here is only to use the
> MIME type for ambiguous or unspecified types. A client that is type-aware only
> uses the MIME type if it's provided, and falls back on the itemtype otherwise.
> A client that doesn't know about MIME types just sees the 9.
I think that if we're going to clean up our act on filetypes, that this
isn't the simplest way to go.
The whole notion of putting filetypes in the URL is something that
doesn't really work all that well already, since it breaks relative
linking. I also think that the whole question of how to deal with
single-character filetypes is so complicated that trying to rely on them
too much is not going to be a fruitful path. Gopher is all about
simplicity, and if it takes pages to explain to server and client
authors how to deal with these single-character item types, we haven't
Perhaps what we need is a way for clients to signal they understand an
enhanced protocol -- call it say Gopher++ -- and when the server
receives a request using this protocol, it can send the MIME type and
perhaps document size before the document.
MIME type-handling libraries are common on just about every platform,
and if people don't want to use them, they can match the bit before the
slash and come up with a really quite good approximation of the
single-character file types.
If we are still going to put MIME types into URLs, why not put them at
The item type is not really for the server's benefit anyhow.
[gopher] Re: Item Type Suggestions, Jay Nemrow, 2008/07/22