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

[Camm Maguire]

Greetings!

Bill Page <address@hidden> writes:

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

The small patch needs to be applied (to o/file.d) and saved_gcl
recompiled.  If this is an obstacle, please let me know.  I could
provide a loadable accept if needed.


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

This obviously has advantages in portability and features -- nice
suggestion!  The memory footprint might be quite high, but one
doesn't have to use the browser, I suppose.  And I hope we don't have
to get into issues of conflicting browser capabilities, etc.   I
suppose it is important that the help browser offer dynamic content,
as it does currently.  Otherwise, with static examples, one could just
launch a separate browser process pointed at an html documentation
tree.  For dynamic content, your idea above is the way to go.

We will have to address the following at some point should we go down
this road:

1) axiom hyperdoc forks on each connection -- this leaves the
   controlling terminal free to pursue other work, but any changes
   therein after the browser was launched would be invisible to the
   borwser process.  Might need to watch the number of connections
   here. 

2) The axiom read loop spends a fraction of its time polling for
   activity on the hyperdoc channel, and processes it immediately and
   serially when present.

3) The user locks the controlling terminal with the browser server
   function, which is terminated when the browser is shut down.

Also we have the issues of

4) persistent connections, or we write an involved state machine with
   cookies, etc. 

5) connecting the hyperdoc documentation to the pamphlet files in a
   seemless fashion -- would be wonderful to be able to inline the
   examples here.

And I thought I'd mention

6)  I have code which implements an SSL encryption over-layer should
    we ever need this, though I can't imagine why we would.


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

Then I think we need either you or Mike Thomas to test this little
example.  There may be unresolved socket issues on Windows remaining,
though we have sucessfully tested little netcat examples earlier as
posted to gcl-devel.  Please let me know of any difficulties.

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

All extremely well taken!  

Two thoughts:

1)  There are so many ??ML variants that appear to come and go in a
    quasi-faddish manner, at least to an outsider like me.  Would be
    great if we can stick to something simple, universal, and eternal
    :-).  

2)  I'm wondering if a browser interface like this might also be able
    to provide some kind of integrated 'inlined-notebook' that at
    least the old mathematica versions had.  Math, text, TeX, and
    graphics all inlined in the sequence in which one works.  Like
    texmacs, I suppose, or imaxima for maxima using my favorite
    program -- emacs :-).  Can we centralize on one interface?  Would
    this be advisable?

Take care,


> Regards,
> Bill Page.
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah