From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,38d1fe109cd56c87
X-Google-Attributes: gid103376,public
From: tmoran@bix.com
Subject: Re: XML-HTML Forms local execution was RE: GNAT, LINUX, KDE
Date: 1999/11/28
Message-ID: <cvh04.350$vq2.31927@typhoon-sf.snfc21.pbi.net>#1/1
X-Deja-AN: 554183608
References: <NBBBJNOMKDIAJALCEFIJKEMIDFAA.rleif@rleif.com>
X-Complaints-To: abuse@pacbell.net
X-Trace: typhoon-sf.snfc21.pbi.net 943825992 206.170.2.144 (Sun,
 28 Nov 1999 13:53:12 PST)
Organization: SBC Internet Services
NNTP-Posting-Date: Sun, 28 Nov 1999 13:53:12 PST
Newsgroups: comp.lang.ada
Date: 1999-11-28T00:00:00+00:00
List-Id: <comp.lang.ada>

>The original and current problem is:
>To create Ada software for processing HTML including HTML forms that
>will work totally on the client computer (PC). I wish to use HTML forms as
>the front-end for a project.
  There are two different things here: HTML processing (ie, a browser),
and acting as an HTTP server.  They are two separate, communicating,
programs, running on the same or two different machines.  There may
be a third (or more) program invoked by the server to accept filled
in form entries and send back results.  That normally runs on the
same machine as the server.

>This application can not be interrupted
>except perhaps by CTRL-Alt_Del or the reset button.
  The machine running the browser cannot be reset?  Or the machine
running the server + forms-handler-program cannot be reset?  Or one
machine is running both?
  A browser that handles full HTML, ie, displaying things in the
right fonts, with images and clickable links, is a substantial
project (Note the size of Netscape or IE).  I certainly wouldn't
propose to write a browser in any small number of hours.
Perhaps with a _heavily_ restricted HTML subset.
  It would be easiest if you could use a COTS browser.  That would
likely mean it's running on a Windows version that is unprotected
from a user killing the browser, or turning off the machine.

  A server seems much easier to subset, and a useful one can indeed
be written in a few hours and a few hundred lines.  (I expect one to
join the sample programs distributed with CLAW.) Since it's a small
program that can be customized, it would be easier to have it
running under an OS where it could not be so easily killed by a
user.  Or it could run on a machine that is physically protected
from user access.

  As pointed out elsewhere, a server will normally process a GET
request that has a program name instead of a file name, by copying
the query part of the request string into an environment variable
named QUERY_STRING, and then calling the named program.  The
QUERY_STRING is a set of name-value pairs in a simple syntax.  David
Wheeler has posted a set of Ada packages that can easily be called
by such a program to fetch information from QUERY_STRING.  A POST
sends info to the server like a data file, instead of in a (limited
size) environment string.
  Since you control the html files, you know exactly what HTTP
subset your server needs to handle, and what it can handle in
non-standard ways.  For instance, your server might call a
subroutine, passing the query string, instead of using the
environment variable + separate (cgi) program approach.

  I'd be inclined to create a component for that along the lines:

package Special_Server_Package is
  use Claw.Sockets;
  type Server_Type is new Server_Type with null record;
  procedure Get_Handler(Client : in out Socket_Type;
                        Path   : in     String;
                        Query  : in     String);
  -- Called to process a GET request from Client.  The request is
  -- parsed just to separate the Path part from the Query part
  -- (if any).  The default implementation, if not overidden,
  -- is to send the file back to Client if it's a file request,
  -- or to put Query into the environment and execute the program
  -- at Path, in the normal HTTP server style.
  procedure Post_Handler(Client : in out Socket_Type;
                         Path   : in     String);
  -- Called to process a POST request from Client.  The default
  -- implementation, if not overidden, is to put the data from
  -- the client in a file, then execute the program at Path, in
  -- the normal HTTP server style.  An overiding Post_Handler
  -- should read the data directly from the Client socket.
  ...