[gopher] Re: Gopherness
Now this is only my opinion, but what I see in many of these threads is a basic lack of understanding of what Gopher0 currently is. Before we move forward, we MUST see where we are. What exaclty DO our EXISTING Servers and Clients recognize or ignore? What exactly ARE the consistently implemented Gopher Protocol standards (if any)? If I choose to use one of the little used features on my Existing Gopher Server, is it actually compatible wit the majority of Existing Gopher Clients?
Lets get some facts together. Lets test our EXISTING Servers and Clients, and create some tables that list features, abilities, etc.; so we can perhaps write a TRUE RFC that sets true STANDARDS that all Gopher0 Protocol Servers and Clients (both OLD and new) MUST adhere to!
--- On Mon, 8/4/08, Jay Nemrow <jnemrow@quix.us> wrote:
From: Jay Nemrow <jnemrow@quix.us>
Subject: [gopher] Re: Gopherness
To: gopher@complete.org
Date: Monday, August 4, 2008, 3:30 PM
I don't doubt the usefulness of a new gopher-ish protocol especially
when compared with Gopher, that was a comparative (to FTP) lightweight
when it was created. I don't say that people shouldn't create new
things, but to change the protocol means that the old one is gone.
Kaput. Old clients will not work anymore (with "updated" servers)
and
no one is supposed to care that they don't work anymore. Gopher has
been somewhat unique because it is still useful in spite of being
frozen in time. Ten year old c64 clients still work with gopher
servers and you can access a file (if you want to) through gopher.
Building clients and servers are a great beginning work in socket
programming before you graduate to tougher protocols. I have given
these justifications before and I tire of bringing them up time and
time again.
When you talk to port 70, an internet server expects to converse in
Gopher. This is established and has been for years. If you want to
speak another protocol, get yourself another port. This is also the
established way to handle new protocols that refuse to be
backward-compatible with established protocols.
If you guys who want an essentially new protocol go off and do that,
it hurts no one. gopher continues and whatever work you produce can
press forward. If you want your servers to do gopher, your new
protocol, and a few others, that is wonderful and great and you have
much precedent for your work, as there are gopher/web servers out
there. I say, go for it.
If you people insist on breaking old gopher clients and servers, you
are being destructive and people who prefer the original protocol and
like to serve content viewable on 80s era computers will be cut off.
Gopher will no longer do that job. I think it would be rather
disingenuous to call the new protocol gopher, as it will not be what
UMN produced (sounds like it won't work with it, either) and what they
named after their mascot. It almost smacks of trademark infringement
(though that is probably a stretch) to break the original.
My basic question is: Must Gopher0 be destroyed (or broken) for
people to find happiness here? Can't you guys make a new name and
register a new port assignment along with creating your new gopher-ish
protocol?
If Avery wants a new mailing list, I propose that it be created with
the intent of talking about the "New" gopher. That is always what
justified a new mailing list in the past - taking a new direction.
On Mon, Aug 4, 2008 at 11:54 AM, Kyevan <kyevan@sinedev.org> wrote:
> Jay Nemrow wrote:
>> "Updated" nostalgia is not nostalgia at all.
>
> Sure, but an improved Gopher could have practical uses. I think,
> perhaps, it might be a better idea to start from nearly scratch and
> create a new protocol that takes the best ideas from Gopher (the
> simplicity of the client! the structured layout!) and add and modifies
> features that we feel would be useful (Replace the limited item type
> system with something based on MIME types (which has the useful fallback
> of "display unknown text/* types as text, everything else unknown
should
> be treated as application/octet-stream"), sending some metadata in
the
> response, perhaps define a way to send requests with data).
>
> This is different than extending Gopher in that we DON'T worry about
> backwards compatibility - at least, not on the protocol level. Servers
> that speak both Gopher and Comepher (or another bad pun, since those
> seem to be inevitable) would be a Good Thing.
>
>
>
Reply to: