Received: with ECARTIS (v1.0.0; list gopher); Wed, 20 Mar 2002 18:00:03 -0500 (EST) Return-Path: <rhahn@tenletters.com> Delivered-To: gopher@complete.org Received: from quarry.com (mail.quarry.com [205.189.158.4]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 0FB0A3B840 for <gopher@complete.org>; Wed, 20 Mar 2002 18:00:03 -0500 (EST) Received: from [205.189.158.32] (205.189.158.32) by quarry.com with ESMTP (Eudora Internet Mail Server 3.0.1) for <gopher@complete.org>; Wed, 20 Mar 2002 18:00:03 -0500 Mime-Version: 1.0 X-Sender: rhahn@mail.quarry.com (Unverified) Message-Id: <p05010406b8bebf1c74fa@[205.189.158.32]> In-Reply-To: <20020320165126.A2219@mothra.dyndns.org> References: <178013C0-3C4B-11D6-B325-0003930BF072@complete.org> <20020320165126.A2219@mothra.dyndns.org> Date: Wed, 20 Mar 2002 18:00:12 -0500 To: gopher@complete.org From: Robert Hahn <rhahn@tenletters.com> Subject: [gopher] Re: The road ahead Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 517 X-ecartis-version: Ecartis v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: rhahn@tenletters.com Precedence: bulk Reply-to: gopher@complete.org List-help: <mailto:ecartis@complete.org?Subject=help> List-unsubscribe: <mailto:gopher-request@complete.org?Subject=unsubscribe> List-software: Ecartis version 1.0.0 List-ID: Gopher <gopher.complete.org> X-List-ID: Gopher <gopher.complete.org> List-subscribe: <mailto:gopher-request@complete.org?Subject=subscribe> List-owner: <mailto:jgoerzen@complete.org> List-post: <mailto:gopher@complete.org> List-archive: <http://www.complete.org/mailinglists/archives/> X-list: gopher

<massive snip>

>Well, a while back I think there was a thread where we were talking >about what makes gopher gopher, and people were talking about avoiding >reimplementing HTTP in terms of gopher, etc. > >When making protocol changes, I think this question is important: >"what is gopher to you?" What should gopher be able to do? What >areas should it not mess with? Which parts of Gopher+ were good, and >which were just lousy ideas? > >Basically I'd like to know what we want Gopher to be so we can make >protocol changes to reflect expected functionality. What I don't want >to do is make protocol changes and end up with a *new* batch of >completely unused functionality with the added benefit of having >broken all backwards compatibility.

This is why I like gopher now: 1) it's *extremely* lightweight - there's almost nothing there. 2) It's claimed to be *extremely* fast. 3) You can pick it up in about 2 seconds. Well, maybe 20 minutes. But the important thing is, you're not required to learn how to do html/javascript (a discipline I've been practicing for 7yrs now) or other tricky stuff.

The biggest problem that I see is that it's hard to extend. Adding mimetypes would fix some of that.

I wish gopher would permit people to send data back to the server. One reason why I think the web exploded in #'s of users is that there was two way interaction (through html forms). Amazingly enough, email has that very same quality - and look how popular *it* is. Gopher is a one-way street, more or less. For those who'd disagree, sending requests could conceivably be sending data, but there's too little flexibility in the kinds of data to send back.

Does it solve any problems that http doesn't? Right now, I believe the answer is no, not really. I'd love to hear comments to the contrary, though...

Are there problems that neither http or gopher addresses? Pick one or two of those (especially if it's easy to explain to laypersons so they see it as a 'burning need'), solve them really well, and we could be on the road to bigger mindshare...

-rh