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: "Avery M." <averym@xxxxxxxxx>
Date: Tue, 8 Jul 2008 16:34:09 -0400
Reply-to: gopher@xxxxxxxxxxxx

The GIF and image types are necessary because they tell the browser
that an image can be displayed in an image viewer (e.g. within a
graphical browser) and doesn't needed to be passed to another kind of
handler. Filetype sniffing is IE's mark of the beast which should
absolutely not be allowed to contaminate any other protocol.

On Tue, Jul 8, 2008 at 4:24 PM, JumpJet Mailbox <jumpjetinfo@xxxxxxxxx> wrote:
> Agreed.  Keep types "0" to "9" and "i" only (throwing most everything under 
> type 9, including text files with extra control code suff such as DOC and 
> RTF, even though they CAN be read in a text reader... try it yourself), and 
> depreciate all other types (including "h" - html, "g" - gif, and "I" - 
> image)!!!
>
> Is this Item Type system favorable to everyone?  If so, I will reconfigure my 
> server now.
> --- On Tue, 7/8/08, Mate Nagy <k-zed@xxxxxxxxxx> wrote:
>
> From: Mate Nagy <k-zed@xxxxxxxxxx>
> Subject: [gopher] Re: Item Type Suggestions
> To: gopher@xxxxxxxxxxxx
> Date: Tuesday, July 8, 2008, 10:35 AM
>
> On Tue, Jul 08, 2008 at 08:27:28AM -0600, Jay Nemrow wrote:
>> I am really against anything besides true text files being classified
> under
>> 0.  Neither DOC nor RTF files are text files and would break all existing
>> gopher clients.
>  fully agree
>> I much prefer putting almost everything under 9, just because older
>> clients will do something that is very acceptable - it will download
>> and store the file as a binary, which any viewer an handle.
>  also fully agree.
>  Binary files (doc, mp3, rtf, what have you) are binary files. Let the
> user handle them. IMHO, even building in movie playing support or any
> other sophisticated file type discovery into a gopher client is
> overdoing it (except for image types, which is often handled by image
> loading libs).
>  Let's keep the ease of implementation of clients in mind (that's one
> (or *the*) massive advantage of the gopher protocol).
>
> Mate
>
>
>
>
>



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