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