[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [gopher] PyGopherd - PYG and executable help



Hi Kim,

The HTTP gateway built-in would be ideal in my opinion (i.e., similar to the
Handlers in PyGopherd, everything goes to port 70, and it handles the
various protocols internally; what we do is simply setup the
firewall/reverse proxy to forward all requests for fqdn:80 to gopherd:70,
and pygopherd does the rest).

The FTP gateway also sounds like a promising idea, however I'm not sure how
forms/inputs would work. Note I'm not really a developer, nor know the
gopher or FTP protocols that well.

What about an option to call gophernicus (i.e., from PHP or another script)
and retrieve data to stdout, for example? That way you can have the best of
both worlds (built-in, plus external web server/script support without
sockets). Any local CGI-capable httpds could then call the gophernicus
binary, passing it the parameters to retrieve the relevant data/resource.

I have been working on a "universal" HTTP to gopher gateway. It however does
not play that nicely with gopherds, as it simply takes the gopher chroot and
parses it on its own--it renders HTTP based on the file system and my
interpretation of the RFC, not through the gopherds. This in my view also
has its ups and downs. It's convenient because it's gopherd-agnostic, drop
it into any environment and it works, and renders in a consistent manner. It
sucks because it doesn't handle executables (or anything else for that
matter) from the gopherds, so both the gopher protocol interpretation and
script execution need to be re-implemented in full within the HTTP gateway.

Regarding the compile on OpenBSD, you will be glad to note (as I was) that
it was completely painless and without error. I did not need to modify a
thing. There was one warning:

gcc   gophernicus.o file.o menu.o string.o platform.o session.o -o
in.gophernicus
string.o(.text+0x608): In function `strnencode':
: warning: sprintf() is often misused, please use snprintf()

Kind regards,
Art

-----Original Message-----
From: gopher-project-bounces+art=poorcoding.com@lists.alioth.debian.org
[mailto:gopher-project-bounces+art=poorcoding.com@lists.alioth.debian.org]
On Behalf Of Kim Holviala
Sent: 04 July 2011 12:26
To: gopher-project@lists.alioth.debian.org
Subject: Re: [gopher] PyGopherd - PYG and executable help

I just started coding Gophernicus again a week ago and have already added
some new features. Right now I'm trying to come up with a simple way of
adding that missing HTTP gateway which will be the next major feature
(thanks to Firefox loosing Gopher support without addons).

Anyway, I'm currently trying to decide between an included HTTP gateway
running on port 70 and external PHP gateway running on top of some other web
server software. Both have their ups and downs... I like the intergated
thingy more, but it's got a problem with the port 70/TCP outgoing being
blocked in quite a lot of places.

Then there's this crazy idea of skipping HTTP and just doing an FTP
gateway.... FTP and Gopher are pretty close actually and FTP is already
supported everywhere :-). Besides, HTTP is booring but running Gopher sites
over FTP would be geeky.

> BTW - You can add OpenBSD 4.9 amd64 (gcc 4.2.1) and Debian 5.0.8 amd64 
> (gcc 4.3.2),  to the list of compiled-and-working-for-Gophernicus :)

Good. Did you have to fiddle with the HAVE_STRLCPY define in gophernicus.h
to make it work on OpenBSD? By default Gophernicus includes its own copy of
strlcpy() but since OpenBSD's got one already I'm not sure what happens...


- Kim




_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project




Reply to: