[gopher] You think MIME types is the killer feature ? LOLz

denis Bernard denis.bernard at laposte.net
Fri May 11 18:27:51 UTC 2012


Wesley Teal <wesleyteal at ...> writes:


> Does nb2gopher create a gopher+ menu? It doesn't seem so from looking
> at the code, but I'm not that well versed in fortran. Also,
> gopher://oceamer.com runs a non-gopher+ server, so I couldn't check to
> verify that your phlogs there worked with gopher+.

I appreciate you have spending time to have a look over my modest gopher hole
and nb2gopher!

My server is GoFish because it is the only one packaged by my Gentoo Linux
distro... I like this server because it works under only one thread, is robust,
written in C, easy to manage, not using Xinetd nor scripting language. However,
I have tested two other well known gopher servers (Bucktooth and Gophernicus)
and I kept my GoFish because it good enough for my needs.  My gopher hole is not
a Gopher+ site, because GoFish is not. When I wrote nb2gopher my preference was
for the earliest Gopher protocol (RFC 1436): I usually prefer simple things. My
good opinion about Gopher+ is somewhat recent and due to the fact I imagined a
popular use of the gopherspace by converting Atom feeds into Gopher; and the
rfc-1436 Gopher cannot be used for a project to write a converter Atom->Gopher.

What I understand from that I read those last days on this list: people want
their client able to handle the Mime type and they are complaining about ending
period. The funny thing is that Gopher+ provides perfectly those two features!
And Gopher+ can do more of that! For sure, an efficient gopher+ client must be
graphical, not console ncurses based. So, taking in consideration that the time
spending to write a soft from scratch is more a question of monthes than weeks,
it is important for developers to have the assurance that their future soft will
be compliant with servers/clients of the future. If some gopher lovers want to
change the rules, for sure developers will be discouraged to write an Gopher
application!

An other desiderata from that people is to make Gopher protocol interactive. But
interactivity with Gopher is possible, even with gopher-rfc-1436! I remember
somebody that used his gopher hole as phlog and handing readers comments via a
telnet connection. I read here that telnet is obsolete? But it is not forbidden
to use telnet! And applications for telnet are so simple to write when running
under a Xinetd server! And a today Gopher-rfc-1436 client can manage a telnet
connection, even those with a password!

Regards,
-- Denis




More information about the Gopher-Project mailing list