Date: Thu, 6 Mar 2003 13:06:28 -0600
From: John Goerzen <jgoerzen@complete.org>
To: gopher@complete.org
Subject: [gopher] Re: PyGopherd 2.0 roadmap
Message-ID: <20030306190628.GB6802@wile.excelhustler.com>
References: <E18r08x-0002bW-00@odie.runbox.com>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E18r08x-0002bW-00@odie.runbox.com>
User-Agent: Mutt/1.4i
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org

On Thu, Mar 06, 2003 at 06:30:59PM +0000, Timm Murray wrote:
> > I hope that you'll be able to, for instance, take a CGI that outputs
> > gopher directories and view ir properly via HTTP.
> 
> I think "CGI" is the wrong term to use here.  CGI is a standard that is tie=
> d=20
> closely to HTTP. While some ideas of CGI can be used (like writing to STDOU=
> T), we=20
> need a way to execute arbitrary code that better supports the peculiarities=
>  of Gopher.

I mean literally CGI.  The idea is to pass CGI-standard environment
variables to programs, and let them output Gopher code -- a gopher directory
or file, handling the typing themselves.

This would mean people to use, to a certain extent, existing CGI libraries
for coding.

Maybe it's not necessary.  I'm curious how PHP was coerced to run under
Bucktooth, really :-)

> So I think we need to come up with a new standard for excuting programs and=
>  call it=20
> something other than "CGI".  It should be easy enough to explain to people =
> that=20
> "foo" standard is just Gopher's version of CGI.

We've already got three:
 * UMN style
 * Bucktooth style
 * PYG (PyGopherd python style)