[gopher] Re: Gopher server-side programming

[David Allen <s2mdalle@xxxxxxxxxxxxx>]

On Sun, Jan 07, 2001 at 09:41:55PM -0800, emanuel at heatdeath organisation 
wrote:
> 
> > What I haven't done before is implemented a non-HTTP servlet.  I'm not
> > digging the idea of writing the gopher equivalent of jserv.
> 
> Aw come on, it'd be fun!  :-)
> 
> I don't know what would be better: trying to tie servlets in with an
> existing gopher server, or writing a gopher server from scratch that
> supports servlets.

Why not choose the middle path, and steal source from something that
already supports it?  I'm not sure what apache's license is for all
the various components (or is it all unified apache license)?  But
there may be a way to borrow the basics of the framework to support
jserv.  I think jserv is GPL'd, but it is very much intertwined with
apache. 

> I haven't dug into gopher servers much, but I'm definitely not very
> happy from user's perspective with any of the servers I've tried,
> especially when it comes to Gopher+ support and programmability.  
> 
> Actually implementing gopher support for servlets would be fairly easy,
> I think, and getting it hooked to an existing server wouldn't
> necessarily be that difficult either (depending on how good the code of
> the server is).

Well, FWIW I've been checking out UMN recently, and I think a lot more
of it now than I did when I started, but I'm not yet to the point
where I know enough to say it would be a good idea to try to staple
this onto UMN gopherd.

> I think writing a fully Gopher+ supporting gopher server would be more
> difficult.  But even that wouldn't be so much harder than writing a
> client, and it only took me a couple of days of coding to get the
> protocol part of a client written (with full Gopher+ support).

Yeah, I think it would be much more difficult.  Plus, I've posted here
and to the newsgroups questions about what the right behavoir is given
the protocol, and sometimes it doesn't matter what the right behavior
is, you still have to support old clients. 

As for writing a server, a basic server would be easy.  But if you
check out what some of the others offer, authentication, running shell
scripts, special formatted files for links/ASK blocks, it gets much
more complex - remember in the gopher protocol it says all of the
intelligence resides in the server, which may mean that programming a
client is quite a bit easier than programming a server.

Plus things like views ... conceptually they're easy, but you'll have
to come up with a clean way for the gopher admin to represent them,
for the server to gather the information...I don't think it's going to
be as easy as writing a client.

> Altogether, I think writing a Gopher+ implementation in Java that uses
> Servlets for everything would be the easiest approach.  Then a Servlet
> could be written to implement UMN gopherd-like file and directory
> serving from the file system.

I'm not clear here - are you talking about writing a gopher+ server in
java, and having it support servlets, or hooking a servlet system into
a non-java server?
 
> Probably the most challenging part would be speccing out the API for a
> Gopher Servlet.

Shouldn't be too hard - most of it is already given to you by the
servlet API, no?

> The more I think about it, the more fun it sounds!

Well, now that you mention it...yeah.
-- 
David Allen
http://opop.nols.com/
----------------------------------------
"I generally avoid temptation unless I can't resist it." -- Mae West