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

[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: JumpJet Mailbox <jumpjetinfo@xxxxxxxxx>
Date: Fri, 4 Jul 2008 21:05:27 -0700 (PDT)
Reply-to: gopher@xxxxxxxxxxxx

Nothing says we can't scrap the "Letter" Item Types (except for "i" = 
Informational Text), and stick to nothing but the Numbers.  This would NOT 
break backwards compatability, and it seems to cover most contingencies.
 
JumpJet would support such a move, as long as the "Unix/Macintosh" crowd used 
"file extensions" on all the files they place on their Servers!!!

--- On Fri, 7/4/08, Cameron Kaiser <spectre@xxxxxxxxxxxx> wrote:

From: Cameron Kaiser <spectre@xxxxxxxxxxxx>
Subject: [gopher] Re: Item Type Suggestions
To: gopher@xxxxxxxxxxxx
Date: Friday, July 4, 2008, 11:15 PM

> 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.


      


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