[gopher] Re: Item Type Suggestions

[JumpJet Mailbox <jumpjetinfo@xxxxxxxxx>]

The WWW also has had issues with people not willing to support older Browsers, 
and there is a campain to try and fight the trend there as well.
http://www.anybrowser.org/campaign/index.html
 
At least with Gopher, we still (in 2008) have have not yet abandoned supporting 
the older Clients, and can still insist on their support.  Personally, I LIKE 
to be able to surf from my DOS machine, and I am sure Cameron enjoys surfing 
from his C64.

--- On Mon, 8/4/08, Jay Nemrow <jnemrow@xxxxxxx> wrote:

From: Jay Nemrow <jnemrow@xxxxxxx>
Subject: [gopher] Re: Item Type Suggestions
To: gopher@xxxxxxxxxxxx
Date: Monday, August 4, 2008, 1:36 PM

This is getting tiring for me and I really hope it is for other
people.  We need to establish our standards soon or we will be getting
the same divergence for eternity.

It sounds like we are still wrestling over a very basic idea - do we
care to if we abandon gopher0 and break older clients?  Kyevan seems
to be voting to do away with the old stuff and pursue a new course.
If we are to move forward, we need to decide if we are honoring
gopher0 as it stands or not.  If we are not going to worry about
backward-compatibility, why are we even using Gopher as a base?  Throw
it out and redesign a new protocol that makes sense given modern
realities.

I think I understand why many people would rather just jack-up gopher
instead of admitting that they are building something new - gopher
already has a presence (a very weak one) and something new would have
to build a new audience.  It is easier to simply hijack the tiny
gopher audience and make them do upgrades.  I am not going there and
anyone else who respects any kind of netiquette should not be going
there either.

I will head off an accusation now, though I know people will fling it
anyway - I am not against adding new functionality to gopher servers
and clients!  What I am against is essentially breaking gopher
(especially older clients) to get this new functionality.  Gopher has
ways to add new abilities that don't break old things.  We need to
stick with that if we are interested in gopher at all.

In respect of those of us that don't want to break the backward path,
I say the rest of you should find yourselves a new name, get
yourselves a new port assignment, and leave port 70 and gopher be.  I
am getting the impression that a lot of people are just looking to
take the real estate that is port 70, usurping what little audience it
has left, and telling the gopher protocol people to basically get
lost.  Here is my response:  Find your own protocol port/name and quit
trying to steal gopher's.

On Sat, Aug 2, 2008 at 7:18 PM, Kyevan <kyevan@xxxxxxxxxxx> wrote:
> 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.
>
> As a practical matter, for the moment, it might be easiest to just
> prohibit message/* and multipart/*, since the only use I can see
> gopher-wise would be multipart/appledouble, and there it makes more
> sense to use binhex and item type 4. example/* and */example are
> entirely invalid (outside documentation), of course!
>
> video/* and model/* could be either shoved under 9, or we could define
> 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...)
>
> 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
> would be nice to have SOMETHING to put in a MIME type-related field for
> menus, if for no other reason than to look nicer to humans reading the
> menu... and besides, then you could do stupid things like return gopher
> menus over http :P
>
> -- Kyevan
>
> Jay Nemrow wrote:
>> Also, if we are to deal with mime types at all, I am thinking that all
>> of them must be put under the 9 item type, no matter what, just to
>> keep old clients from breaking.  If you put a .doc file under the 0
>> menu type, the old client wants to dump that to screen as text and you
>> will see gibberish and probably crash things.  Everything that
doesn't
>> fit into the established types will have to be 9 item types, as far as
>> I can see.
>
>
>