[gopher] Re: Item Type Suggestions

[JumpJet Mailbox <jumpjetinfo@xxxxxxxxx>]

Enough already:
Once again in this discussion I read statements like "but would possibly break 
compatibility with older clients".  
 
Stop guessing, and FIND OUT if the older Clients support these Item Types or 
not.  There are not that many Clients, and they ALL can be found at:
gopher://home.jumpjet.info/11\Begin_Here\Clients

A suggested expanded list of Item Types (written after Gopher went mainstream) 
was offered in section 3.8 of of RFC1436 
gopher://home.jumpjet.info/00\Begin_Here\References\rfc1436.txt
 
However, and this is important, not all Clients even supported all of these 
(much less those oddball ones like ";")!  The ONLY WAY we will ever know for 
sure what is or is not supported is to just test ALL the old Clients, and write 
the results in an Item Type support table... simple, direct, and necessary (if 
we intend to move forward that is).
 


--- On Mon, 8/4/08, Cameron Kaiser <spectre@xxxxxxxxxxxx> wrote:

From: Cameron Kaiser <spectre@xxxxxxxxxxxx>
Subject: [gopher] Re: Item Type Suggestions
To: gopher@xxxxxxxxxxxx
Date: Monday, August 4, 2008, 1:08 AM

> What about the whole world of text-based formats? (text/*)?
> 
> I think it might make most sense to put text/* under 1, application/* 
> under 9, image/* under I, and audio/* under s.
[...]
> video/* and model/* could be either shoved under 9, or we could define 

Actually, video, for no good reason, has a history of being under ;
(semicolon). Don't ask me why; this is what I saw used back in the day, so
it has historical weight behind it.

> item types for them. Having item types that parallel the base Internet 
> media types seems like it would make sense and would ease conversion... 
> but would possibly break compatibility with older clients. Actually, I 
> and s have that problem too, though they're wide-spread enough to be 
> mentioned on Wikipedia (which, admittedly, could just be one editor 
> using them...)

No, these have pretty good historical weight also. Still, although I
concede they are nice for user conceptualization, these sorts of gestalt
types make me tear my hair out as a client author since they're not
deterministic.

I'm considering a facultative mode for Overbite where if it sees a MIME
type embedded in a Gopher URL, it will honour it and strip it out, and
use that to override the item type. I have not yet determined if I'm going
to implement that, but it would be nice for convenience. This would be
independent of what the server does so that people could force a MIME type
on a particular URL and make Overbite "do what I want."

> Add fallback types to the hypothetical pie-in-the-sky Gopher Perfect 
> that will be specified around the same time as all that vaporware
we've 
> been 'promised' over the years comes out, I guess. :P
> 
> Additionaly, might we want to use something like 
> application/[X-]gopher-menu as a type for 0? I mean, it seems like it 

Do you mean type 1? I think something like application/gopher-menu (no x-)
is already in use for that. Overbite uses its own pathological string but
that's mostly to override Mozilla's internal support.

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@xxxxxxxxxxxx
-- lp0 reported invalid error status (on fire, eh?) -- Linux 1.1.62 -----------