Date: Mon, 8 Jan 2001 18:37:23 -0800
From: emanuel at heatdeath organisation <emanuel@heatdeath.org>
To: gopher@complete.org
Subject: [gopher] Re: Gopher server-side programming
Message-ID: <20010108183722.A15199@success-info.com>
Mail-Followup-To: emanuel at heatdeath organisation <emanuel@heatdeath.org>,
	gopher@complete.org
References: <20010107211343.C31887@success-info.com>
 <20010108001753.A21293@mothra> <20010107214155.D31887@success-info.com>
 <20010108005513.A24204@mothra>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010108005513.A24204@mothra>;
 from s2mdalle@titan.vcu.edu on Mon, Jan 08, 2001 at 12:55:13AM -0500
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


On Mon, Jan 08, 2001 at 12:55:13AM -0500, David Allen wrote:
> 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. 

Well, I wouldn't start with jserv, since it implements an old version of
the standard.  Also, jserv requires Apache (it's an Apache module),
which doesn't make much sense for Gopher.  Yes, starting with an
existing servlet implementation would be a good idea.  I'd probably go
with Tomcat, since it is what I know and is under active development.

> 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.

Existing gopher servers already do a decent job with this stuff, so it
doesn't need to be redone.  The new gopher implementation only needs to
do enough to support Servlets and hide a lot of the details of the
protocol, but it's up to the Servlet developer to do the complex stuff,
such as creating ASK blocks and views, and deciding what to do with the
result.  If we want the server to do all the filesystem stuff, a servlet
could be written to do it, but it would hardly be the priority.

> > 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?

Writing a Gopher+ server in Java.

> > 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?

Yes, but Gopher is a fairly complex protocol (it has more features than
HTTP) which need to be mapped into an API in a flexible, but easy to
use, way.

-- 
emanuel at heatdeath organisation
gopher.heatdeath.org