[gopher] Re: Item Type Suggestions

[Roman Pavlov <webmaster@xxxxxxxxxx>]

I'm afraid at some point we can lose distinction between "gopher item 
types" and "MIME types" which are not initially the same, and merging 
them we lose "gopher types" as one of main gopher concepts.

As for case with CSS and XML, you mentioned that distinction of MIME 
types is necessary for the client to know which application should be 
run to handle an item. However, both CSS and XML are typically handled 
with the same application as HTML, i.e. web browser, so they actually 
could be put under h itemtype (HTML).

My opinion is that although "MIME types" are more machine-friendly 
allowing the browser to choose and run correct application, "gopher 
types" are more human-friendly as a human user doesn't necessary make 
distinction between different types of movie, sound, graphics files. I 
think this approach should be kept.

Cameron Kaiser wrote:
>>> Particularly for XML, CSS and RSS which may be hosted on a gopher server, 
>>> using 0 for these despite being text/* could quite possibly be seen always
>>> as text/plain and not further interpreted by an external viewer, which is
>>> probably not what we want.
>> Why would this type of content be suitable for a gopher server?  If I
>> had XML, CSS, and RSS to serve up, it certainly wouldn't be done via
>> gopher.
> 
> Realistically, why not? It's just another file. In fact, this whole thing
> came up precisely because of an XML and CSS file that wasn't getting a correct
> item type (Mozilla was content-sniffing it, but this broke in Overbite which
> has a rigid 1:1 mapping).
> 
> I realize that assigning item types for every possible file and/or MIME type
> doesn't scale, but from a technical perspective, people are serving these
> files already -- if we support HTML, then we should be supporting what comes
> with it and at a minimum that will be CSS. The item type space is small, so
> it's more of an aspect of picking and choosing what is important to nail
> exactly for purposes of picking the appropriate viewer, and subsuming the
> rest under generic codes or 9. If we're always relying on the client to do
> the right thing and not hinting it with an exact or at least more specific
> type mapping, that makes for more ungainly clients.
>