Received: with LISTAR (v1.0.0; list gopher); Sun, 07 Jan 2001 23:59:30 -0600 (CST) Return-Path: Delivered-To: gopher@complete.org Received: from gtei2.bellatlantic.net (gtei2.bellatlantic.net [199.45.40.146]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 18D003B807 for ; Sun, 7 Jan 2001 23:59:29 -0600 (CST) Received: from mothra (adsl-141-152-12-101.bellatlantic.net [141.152.12.101]) by gtei2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id AAA15679 for ; Mon, 8 Jan 2001 00:56:38 -0500 (EST) Received: from x by mothra with local (Exim 3.20 #1 (Debian)) id 14FVH1-0006L0-00 for ; Mon, 08 Jan 2001 00:55:15 -0500 Date: Mon, 8 Jan 2001 00:55:13 -0500 From: David Allen To: gopher@complete.org Subject: [gopher] Re: Gopher server-side programming Message-ID: <20010108005513.A24204@mothra> References: <20010107211343.C31887@success-info.com> <20010108001753.A21293@mothra> <20010107214155.D31887@success-info.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <20010107214155.D31887@success-info.com>; from emanuel@heatdeath.org on Sun, Jan 07, 2001 at 09:41:55PM -0800 Content-Transfer-Encoding: 8bit X-archive-position: 49 X-listar-version: Listar v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: s2mdalle@titan.vcu.edu Precedence: bulk Reply-to: gopher@complete.org X-list: gopher 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