Received: with ECARTIS (v1.0.0; list gopher); Tue, 03 Jan 2006 22:46:21 -0600 (CST) Received: from mo-69-69-114-6.sta.sprint-hsd.net ([69.69.114.6] helo=erwin.lan.complete.org) by glockenspiel.complete.org with esmtps (with TLS-1.0:RSA_AES_256_CBC_SHA:32) (TLS peer CN erwin.complete.org, certificate verified) (Exim 4.50) id 1Eu0XT-0003hm-Dg; Tue, 03 Jan 2006 22:46:21 -0600 Received: from katherina.lan.complete.org ([10.200.0.4]) by erwin.lan.complete.org with esmtps (with TLS-1.0:RSA_AES_256_CBC_SHA:32) (No TLS peer certificate) (Exim 4.50) id 1Eu0XJ-00055J-PJ; Tue, 03 Jan 2006 22:46:09 -0600 Received: from jgoerzen by katherina.lan.complete.org with local (Exim 4.60) (envelope-from ) id 1Eu0XJ-0003Qj-Ko; Tue, 03 Jan 2006 22:46:09 -0600 Date: Tue, 3 Jan 2006 22:46:09 -0600 From: John Goerzen To: gopher@complete.org Subject: [gopher] Re: PyGopherd and Gopher+ Message-ID: <20060104044609.GB12981@katherina.lan.complete.org> References: <20051231155642.GA9489@SDF.LONESTAR.ORG> <20051231164643.GB28740@katherina.lan.complete.org> <20051231173023.GA2684@SDF.LONESTAR.ORG> <20060101165144.GA2143@SDF.LONESTAR.ORG> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Spam-Status: No (score 0.1): AWL=0.010, FORGED_RCVD_HELO=0.05 X-Virus-Scanned: by Exiscan on glockenspiel.complete.org at Tue, 03 Jan 2006 22:46:21 -0600 Content-Transfer-Encoding: 8bit X-archive-position: 1227 X-ecartis-version: Ecartis v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: jgoerzen@complete.org Precedence: bulk Reply-to: gopher@complete.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: Gopher X-List-ID: Gopher List-subscribe: List-owner: List-post: List-archive: X-list: gopher On Mon, Jan 02, 2006 at 03:01:41AM -0600, Jeff wrote: > On Sun, 01 Jan 2006 10:51:44 -0600, Benn Newman > wrote: > > > On Sun, Jan 01, 2006 at 08:27:25AM -0600, Jeff wrote: > >> Why don't we write a new spec which would supercede gopher+? > > In the spirit of the original design *grin* we must form a commitee to > > solve a problem. > > Let's do it then, if Mr. Goerzen approves. Of course ;-) > 1) As I wrote in my previous post, I think that reserving new tabspaces > for information like mimetype and filesize would be a good start. The > file's last-modified date would also be nice. I think we're certainly moving in the right direction. Let's think about a few other things. * MIME types and encodings are more complex than they may appear. Say you have a German text file encoded in UTF-8 and then gzipped. Some people would say this is an application/x-gzip file. Others would say it's text/plain with a gzip encoding. But if you put the single file in a tar.gz file, some would say it's an application/x-tar file with gzip encoding, while others would say it's an application/x-gtar file, no encoding. You could take "people" to be "programs" as well. MIME types are handy because they are universal, but they are annoying because that are not understood universally. * It is still a great annoyance to have meta information conveyed by the referring object rather than the object itself. I wonder if we may consider extending the protocol so that a request of a certain form would cause a compliant server to send a single line of meta information before sending the document as usual. This single line of meta information could even be in the form of a regular (gopher++ is it now?) menu line. It seems to generally be the case, both in filesystems and in browsers, that meta-information is obtained by the object itself, not the object the refers to it. IE sometimes looks at the extension of a file to determine what sort of file it is, and this is generally considered a bug. By doing this, we could also reform the gopher:// URL schema. -- John