[gopher] Re: Item Type Suggestions

[Cameron Kaiser <spectre@xxxxxxxxxxxx>]

> Note that letter cases are "neutral", so now type "I" and "i" are BOTH the
> indicators of an "Informational text".
> Modern software has the ability to detect file types and choose an
> appropriate file viewer.

I have two problems with this analysis: first, it really shatters backwards
compatibility, and second, I really don't like large generic class itemtypes
because it places the classification burden on the client rather than on
the server. I very unwillingly supported the overloaded I class in Overbite
only because it is so widely used, and used filename extensions to do the
MIME type mapping, but I consider either extensions or content sniffing to be
fraught with peril. The same goes for other wide types like s or ; which I
worked around by letting Mozilla sort it out.

Also, I think it violates the original spirit of the item types that were
first in place. When you look at the "core 10," i.e., 0-9, each item type
distills down to a specific and unambiguous single client action, even if
(such as in the case of '9') the type could be theoretically anything --
either display it internally, use a specific unpacker, use a specific image
renderer, or save it to disk. There was no ambiguity about what the client
was supposed to do, and as a bonus, user interaction was entirely
deterministic and predictable.

That said, though, how are we going to centralize something like this?
Rather go Postel than Postal! ... poor joke.

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@xxxxxxxxxxxx
-- There are few problems that the liberal usage of high explosives can't cure.