*BSD News Article 48356


Return to BSD News archive

#! rnews 7391 sserve.cc.adfa.oz.au
Path: sserve!euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!zombie.ncsc.mil!news.duke.edu!agate!violet.berkeley.edu!jkh
From: jkh@violet.berkeley.edu (Jordan K. Hubbard)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Was: Future of FreeBSD..: HTML for GUI ?
Date: 3 Aug 1995 06:43:44 GMT
Organization: University of California, Berkeley
Lines: 131
Message-ID: <3vpr70$es8@agate.berkeley.edu>
References: <3vgtgs$ti1@nntpd.lkg.dec.com> <3vo8l5$90d@mars.earthlink.net>
NNTP-Posting-Host: violet.berkeley.edu

In article <3vo8l5$90d@mars.earthlink.net>,
Robert Nusbaum  <rnusbaum@earthlink.net> wrote:
>HTML is the agreed upon method of passing messages
>between client and server.  The problem now is the
>need for CGI programming on the server.  All

Ya know, I wonder about that.  It seems almost ludicrous in some cases to
bring up a full WWW server and write the glue code as CGI scripts which
just, in turn, spit out HTML files someplace else for the sole consumption
of the browser.  Wouldn't it make more sense to start with the stuff
distributed by w3.org and develop an embedable library for giving
an application its own direct httpd capability?  Heck, you could export
the "httpd library" API through TCL, make the server application also
export some TCL API and then just write companion tcl scripts to
glue the server to the browser clients - much more easily extensible
and at a much higher level than CGI.

Wondering what the heck I'm talking about?

OK, let's say we have a server application we'd like to control through
some nifty menus based interface, but we don't want to have to develop some
special custom API for tweaking the server that we'll then have to sit
down and implement a menu-using control client from scratch for.
Too much work.  So we say "Hey, those Netscape folks seemed to have
had the right idea when they wrote their commerce server - they let you
control the entire thing by talking HTML to it over a special port, using
a standard WEB browser!  Cool!  I want that too!"  And then we look
around and think "Hmmm.  What's required to do that?  Is there something
I can just link into my legacy application and get this functionality
comparatively for free?"

I think it's actually not that hard..

You need some sort of API for describing all the various "interactors"
on your screens.  How they present themselves to your average browser
(picture or text description), what happens when you invoke them
(could be one of a set of canned actions or some fairly powerful application
internal function), how they hang together in item/list/menu structures,
etc.  I could see doing this the hard way, which would be some sort of
intermediate language with callback binding ability (for invoking your
application's internal procedures) and a layout syntax for describing
what the "HTML" is going to look like.

I could also see doing this the easy way, which would a couple of
top level functions for the application:

	int httpdLibOpen(int portnum);
		Returns the fd of a socket listening as an "httpd server"
		on port "portnum" (default of 80 if portnum is 0).
		This FD should be or'd into any select() masks the application
		may be maintaining for accomplishing non-blocking "waits"
		on one or more fds.  If the application has nothing else
		to do, it should simply call httpDispatchRequest() with
		the fd returned from this call.

	int httpdLibRegisterTclInterp(Tcl_Interp *interp, int fd);
		This would give the library the handle it needs for
		registering all its appropriate "httpd" commands into TCL.
		It will have been furthermore assumed that the application
		has already initialitzed this interpreter with its own exported
		commands and variables.  The fd argument might be ignored in
		a first-draft implementation but used to differentiate between
		multiple "servers" running from a single application later.

	int httpdLibDispatchRequest(int fd);
		Does a non-blocking read on fd and dispatches an internal
		http message handler in response to request.  Returns 0
		on success, a negative error code if a system error occurred
		or a positive error code if an internal TCL evaluation failed
		(we'd have to think up some realistic error codes for such
		"system" and "user" errors).

		Call the appropriate interpreter instance registered with 
		httpdLibRegisterTclInterp() with a known "message handler"
		command.


That'd be it.  The application would then use the API like this:

1. Create a TCL interpreter and register all your special "exported"
   features with it.  These will be your handles for getting things
   manipulated in response to http requests.

2. Initialize the library and get a server fd back from httpdLibOpen()
   (perhaps it needs to be a little more complex than this to masquerade
   as multiple hosts, but that's the general gist).

3. Register the TCL interpreter and fd with httpdLibRegisterTclInterp(),
   which will also fill in any required functions with default actions if
   the application hasn't or possibly generate an error if some mandatory
   TCL glue function was not provided.

3. Pass the server fd to httpdLibDispatchRequest() when it either knows that
   there is data waiting (through the kind services of select() or SIGIO,
   probably) or it didn't mind waiting.  httpdLibDispatchRequest() will return
   the appropriate action code after invoking something in TCL and then
   the application can go back to whatever it was doing.

Everything of significance would be handled in TCL.  There would be
known TCL words that the application would be expected to have either
declared in its own initialization (for special handling of some
html request) or would be declared by the httpdLibRegisterTclInterp()
routine when it was called.  TCL is pretty flexible that way, and
you can inspect an interpreter's environment pretty closely to see
what's been defined and what hasn't.  The application itself would
probably come with a supplied TCL file of glue code or just have it
compiled in as a static string.  The goal would be to provide a rich
enough set of TCL commands in httpdLib that the glue code could easily
create complex html structures with TCL callbacks attached, throw pre-written
HTML files at the client with one command, etc.  The application has a
very abstract notion of what it's being asked to do, with those actions
being boiled down to whatever basic API they chose to export into the
TCL interpreter.  A database engine could have primitives for creating
new tables, querying existing ones, etc.  An inventory server might
export certain types of data so that any field office with a copy of
Windows and Mosaic could check stocking levels over the WEB, the
possibilities are endless.  Heck, if I was doing all this in TCL for
a database engine I'd also throw the Tk command set in there and
use it to bring up a "watch station" screen on an X display somewhere
and show the httpd traffic (broken down into the various request categories)
as it was coming in.  That would be trivial to add and there are already
some really sexy graphing widgets available in Tk.  I wouldn't have to
write any of that to get such functionality.

All of this could be done now, without the benefit of multiple ports
of java being available (which they're not) and with just a little
bit of hacking..

Hmmm..  Any interest? :-)

						Jordan