Complete.Org: Mailing Lists: Archives: gopher: July 2008:
[gopher] Re: Item Type Suggestions

[gopher] Re: Item Type Suggestions

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: gopher@xxxxxxxxxxxx
Subject: [gopher] Re: Item Type Suggestions
From: Cameron Kaiser <spectre@xxxxxxxxxxxx>
Date: Fri, 4 Jul 2008 20:15:07 -0700 (PDT)
Reply-to: gopher@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: --
  Cameron Kaiser * Floodgap Systems * * ckaiser@xxxxxxxxxxxx
-- There are few problems that the liberal usage of high explosives can't cure.

[Prev in Thread] Current Thread [Next in Thread]