Content-type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
From: "Timm Murray" <hardburn@runbox.com>
To: gopher@complete.org
Subject: [gopher] Re: PyGopherd 2.0 roadmap
Date: Thu, 06 Mar 2003 18:30:59 GMT
Message-Id: <E18r08x-0002bW-00@odie.runbox.com>
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org

> On Thu, Mar 06, 2003 at 07:03:03PM +0100, smoerk wrote:
> > and in the end it is more a http server than a gopher server?
>=20
> Well, it's been both all along.  The HTTP mode is there just for people t=
hat
> don't have Gopher capabilities, but you can (and have been able to) publi=
sh
> Web documents on it.
>=20
> 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.

For instance, how will a "Gopher CGI" give it's data type.  HTTP handles th=
is by=20
having the script output a "Content-type" header.  Outputting a similar hea=
der=20
in Gopher would mean the program would have to be excuted every time just t=
o=20
get a directory listing.

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.