Received: with LISTAR (v1.0.0; list gopher); Sat, 30 Dec 2000 18:29:03 -0600 (CST) Return-Path: Delivered-To: gopher@complete.org Received: from autechre.success-info.com (success-info.com [139.142.115.211]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 876383B805 for ; Sat, 30 Dec 2000 18:29:02 -0600 (CST) Received: from emanuel by autechre.success-info.com with local (Exim 3.12 #7 (Debian)) id 14CWKw-0004X3-00; Sat, 30 Dec 2000 16:26:58 -0800 Date: Sat, 30 Dec 2000 16:26:58 -0800 From: emanuel at heatdeath organisation To: gopher@complete.org Subject: [gopher] Re: Gopher Protocol Issue Message-ID: <20001230162658.A16932@success-info.com> Mail-Followup-To: emanuel at heatdeath organisation , gopher@complete.org Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Content-Transfer-Encoding: 8bit X-archive-position: 14 X-listar-version: Listar v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: emanuel@heatdeath.org Precedence: bulk Reply-to: gopher@complete.org X-list: gopher Cameron Kaiser wrote: > I've also been playing with the gopher->web gateway at > heatdeath.org, which is great stuff. I've just joined and I see I've already been mentioned. That's a good sign :-). Cameron Kaiser wrote: > One would think the problem of testing on > multiple clients would be ameliorated in gopherspace, though. :-/ Well, it's not nearly as bad as with the web. Sure, you have to test server software against many clients when developing (and vice-versa), but putting up a gopher site with established server shouldn't need testing with all clients. David Allen wrote: > In terms of 'popularizing' gopher again, it seems as if any movement > towards gopher again (ala Gopher Manifesto) would need to start at the > browser level, due to the fact that that's what people are addicted to > at the moment. But that's just my speculation. This is why I started my gopher->web gateway (named, suprisingly enough, webgopher). It skips the whole problem of having to build good gopher support into the web browser itself by gatewaying gopher to HTTP and HTML that will work with any web browser. This gets especially important as a trend is to embed web browsers in more and more devices. Point your gopher to gopher.heatdeath.org and follow the links to see the gateway in action. Development is stalled for the moment because work is getting busy, but I'm in the middle of doing full Gopher+ support. Cameron Kaiser wrote: > Gopher+ is sort of a nebulous extension and there are a lot of > inconsistencies in it, the one you mention being one of many. Actually I found that after several passes through the Gopher+ "specification" all the inconsistencies I thought I saw in my initial passes were resolved. I don't think what was mentioned was an inconsistency at all. The spec says that the number of bytes of data must be specified (or -1 or -2). As you said, UMN gopherd happens to not specify the size, and instead gets the client to read until the end, but that was simply their implementation choice. Yes, having to translate the file as it is sent makes it more difficult to specify the size, but the server could cache the actual data size (doesn't UMN gopherd already cache a bunch of stuff?) so it only needs to calculate it once. -- emanuel at heatdeath organisation gopher.heatdeath.org