Re: [Gcl-devel] Simple web server code for GCL for Windows

[Bill Page]

Camm Maguire wrote:

> Greetings!  Here's a quick way to get started:
>
> =============================================================================
> address@hidden:/fix/t1/camm/debian/gcl/gcl-2.6.6$ diff -u ../gcl-2.6.5/o/file.d 
> o/file.d
Thanks Camm!

The diff command suggests that this code is already in GCL 2.6.6.
Is that correct?

Should I expect the code below to work "out of the box" with the
Windows version of GCL 2.6.6?

> > (defun foo (s) 
> >    
>  (let* ((get (read s nil 'eof)) 
> 	 (fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
>          (fn (when (probe-file fn) fn)))
>    (format s "HTTP/1.1 ~S~%~%" (if fn 404 500))
>    (when fn
>      (if (pathname-name (pathname fn))
>           (with-open-file (q fn) (si::copy-stream q s))
>         (dolist (l (directory fn)) (format s "~a~%" (namestring l)))))
>    (close s)))
>
>  
>
> > (defun bar (p fn) 
> >    
>  (let ((s (si::socket p :server fn))) 
>        (tagbody l 
>                (when (si::listen s) 
>                        (let ((w (si::accept s))) 
>                                (foo w))) 
>                (sleep 3) 
>                (go l))))
>
>  
>
> > (bar 8080 #'foo)
> >    
> =============================================================================
>
> Then point your browser to localhost:8080.  You should be able to get
> directory listings and files.  There is obviously no protocol nor
> error implementation here, but that should be straightforward for the
> web gurus.
>
>  
Great, that is exactly what I was looking for.

> This will accept multiple simultaneous connections and process them
> one at a time.  The delay mechanism can obviously be adjusted.  Each
> connection is stateless -- a multiplexing solution for persistent
> connections can be implemented in like manner.  Also, all connections
> are in the same process.  It is trivial to fork() in linux for each
> connection, but don't know how this would be done on Windows.
> Speaking of which, does MS have select?  There are other hooks for
> allowing work in the image while connections are handled in the
> background, e.g. SIGIO, but don't know the portable nor most desirable
> way of doing this.
>
> Anything can be done here that one wishes -- my question is, what is
> the advantage vis a vis an external server like apache?  Presumably,
> axiom could spit out results directly instead of being called in a
> cgi, which is of some value.
Yes! It is a very significant value if one were to try to implement Axiom's
HyperTex browser in a "real browser" as per my previous email and
discussed by Mike Dewar and Tim Daly.

>  Anyway, more discussion on where and why
> this should go if anywhere would be great!
>  
My short term objective is to have a simple way to "prove" the
portability of socket connections in GCL, specifically HTTP
access, between Linux and Windows.

My goal is to be in a reasonable position to argue for the following:

I think that using a browser to implement the Axiom gui would be
an excellent way to solve the problem of porting Axiom HyperTex
and Graphics. It seems an extreme waste of scarce resources to
spend time on re-implementing something based on a model that
is now more than 10 years old - that's ancient given the rate at
which this technology is developing. A browser interface would
also be automatically compatible with the web and easily integrated
into web server applications like MathAction.

I have played with HyperTex as now implemented in the most
recent release of open source Axiom and frankly in comparison
to modern browser interfaces, it looks primitive and awkward.
Except for it's ability to simply navigate Axiom's algebra library,
I doubt that it can have much appeal to current computer users.

NAG did a lot of work on Axiom to make it compatible with
Techexplorer on Windows and to replace the old (even then!)
HyperTex browser with something newer and more powerful.
This included adding special code to Axiom to navigate the
Axiom library that was intended to work with a "real browser".
(Techexplorer was essentially IBM's first entry as a mathematics
capable web browser. It is still available in another commercial
incarnation but unfortunately not as part of open source Axiom.)

NAG also apparently did a lot of work on porting Axiom graphics
to OpenInventor. OpenInventor lead to VRML and is now known
as X3D. Since OpenInventor is now open source, I think we are in
an excellent position to take advantage of this work. VRML is also
well adapted to integration with web applications.

The down side is that as far as I know very little documentation is
available for the work that was done by NAG. I am also not certain
exactly how much of this code was in the source package that was
originally delivered to Tim Daly from NAG. My hope is that someone
like Mike Dewar would be willing to work with us develop the
necessary documentation so that we could adapt that work to
currently available open source software.

The benefits of open source and free aside, if Axiom must compete
with commercial products like Mathematica and Maple for a share
of the academic symbolic computer market, then I think we must
aim a little higher than simply providing Axiom as it existed 10 years
ago. And aside from it's superiority in supporting research in new
mathematical algorithms, there are other features of Axiom (especially
Axiom's graphics) that potentially place it still somewhat ahead of
what is available in the commercial M&M's. I think the sooner we
can make these features available in the open source version of
Axiom, the better chance we will have of attracting some serious
interest.

Regards,
Bill Page.