Slashdot Mirror

← Back to Stories (view on slashdot.org)

Gopher ProtocolHandler for Apache2 Released

Posted by michael on from the go-fer-it dept.

hardburn writes "One of the stated goals of the Gopher Manifesto (previously mentioned on Slashdot) was to create a Gopher plugin for Apache. That goal has now been realized with the release of Apache::GopherHandler. Get it off Gopher itself or off CPAN."

5 of 51 comments (clear)

  1. The 80's called... by infernalC · · Score: 4, Funny

    ...they want their protocol back!

  2. Re:Any advantage? by squiggleslash · · Score: 4, Informative
    There's quite a lot of crap that gets sent with your HTML pages with HTTP, so you can easily end up with as much in headers sent to and from your browser as you have content. Gopher contains no headers of any kind - indeed, file type information is included in the URLs and the URLs are minimal when you're using Gopher's built in menus (ie no description&lt/a&g t - you're literally just sending what IIRC is a simple CSV file containing hostandfile,type,description (it's been a while, I can't remember the exact format.) Getting a gopher page is literally a matter of connecting to the Gopher port, sending the name of the page you want, and reading what comes back until the connection closes. You don't send additional information, the server doesn't send additional information.

    Really it depends on the application whether you're going to want to use Gopher. If you have very little bandwidth to spare, and HTTP's keep-alive would not do enough to minimize the header/HTML overhead, Gopher can certainly help and will almost certainly be an improvement to end users.

    How likely you are to be in such a situation however is open to question.
    --
    You are not alone. This is not normal. None of this is normal.
  3. This is great... by samrolken · · Score: 4, Funny

    I'm glad to see some support for the gopher protocol. It's so necessary, considering the miserable failure of all kinds of other kind of online hypertext protocols, like the World Wide Web.

    --
    Sam Kennedy

    --
    samrolken
  4. Re:Any advantage? by hardburn · · Score: 5, Informative

    One advantage is that any device can support Gopher without doing strange things to the text. Gopher orginizes everything in a heriarchal menu (tab-delimited), and then the client gets to do whatever it wants with it. You don't need to worry about "how does my page look on a PDA screen?", because a theoretical Gopher client on a PDA would already know how to format the output to be readable there. This is specifically because the Gopher protocol is dumb by design.

    Exploring neat ideas for interactions between Gopher servers and clients is my hidden goal behind this project. One idea I have is to make a backend repository for game ROMs that use Gopher+ INFO blocks to send the information on how to execute that ROM for a given emulator. Emulators that require special ROMs (such as MAME, which changes what is actually needed to execute a game in almost every new version) can be handled with Gopher+ VIEWS. But I'll have to get down to implementing Gopher+ before I can do that.

    I don't view Gopher as a replacement for the web, but as a nice augmentation in certain situations.

    --
    Not a typewriter
  5. Re:the gopher url worked! by hardburn · · Score: 4, Interesting

    gopher.quux.org is a huge repository (many of the quotes you see at the top of my site came out of QUUX's fortune files). I eventually plan on expanding gopher.wumpus-cave.net into a repository for weird or historical technology (Trebuchets built out of Legos, PDP-11 assembler opcodes, etc.), but right now it just has some Gopher implementations and some pictures of a burning stuffed Barney doll :)

    --
    Not a typewriter