[Axiom-developer] browser front end, statement of plans and progress

[daly]

I've been looking deeply into the problem of using a web browser
as the front end for axiom. There are 3 components:

1) replace the graphics
2) replace hyperdoc
3) make an interactive front end

Consider problem 1, replace the graphics.

Currently our graphics are written in C and use X11.
The graphics program is really a standalone C program that
communicates to the rest of the system thru sman.

X11 has been a problem because we cannot port this to windows easily.
I did manage to get hyperdoc working on windows using an X11 hosting
program but decided that this was not a good long term solution and
never released it.

Architecturally the choice of making the graphics engine exist outside
of the underlying lisp system has limitations. I would much rather see
a closer integration between the computations and their display so that
the display could be dynamic instead of static graphs. And it should be
possible to create new domains that directly manipulate axiom data
structures that can be drawn directly. A standalone C program is not
a good choice for this.

I've been investigating new browser technology that will allow us to
draw the graphics on a web page in several formats. The first attempt
was to create flash files (an open format) directly from lisp so that
we could write a flash file which had moving graphics (e.g. a moving
wave image). This proved to be painful and I stopped.

Recently a new html tag <canvas> has been implemented. I've been playing
with this tag and it appears to support all of the drawing primitives we
need to do the 2D graphics. Axiom already does the 3D->2D work.

Another recent (well, recent to me) development has been the AJAX
architecture. This allows a web page to dynamically and periodically
communicate to a host without changing the page. This is how google
does tricks like google earth.

So combining these two technologies will allow us to run an axiom
process that communicates with a local or remote browser and can
dynamically draw shapes on the webpage.

The low level task is to refactor the C code into display and
data handling. The display primitives get pushed out to javascript.
The data handling gets sucked into lisp. The C code disappears.

I'm putting together code to do an example for this and I'd like
feedback about the idea and the direction.



Consider problem 2, replace hyperdoc.

I've already coded portions of hyperdoc in javascript and am now
learning AJAX so that I can fetch pages and images from an axiom
session. Also in plan is to be able to dynamically show results
from the axiom session when looking up search and query information.

Hyperdoc used to have its own language for display but this is dead
and gone. I've been recoding the hyperdoc pages into html so they
use a standard format. This will allow anyone to code web pages without
any training. It should also allow us to embed pamphlets as pdf in pages.

The low level task is to recode the hyperdoc info into html and
javascript (in process), factor in new function for handling 
pamphlets and hyperlinking to non-axiom data, and using either
mathml or some other smooth symbol output.

Hyperdoc can display both static (easy) and dynamic (somewhat harder)
graphics output so I'm stalled on the conversion while I work thru 
the graphics details.




Consider problem 3, make an interactive front end

Given AJAX it should be possible to type into a web page, send the
input to axiom, html (mathml?) the output, and display the result.
This will take a bit of surgery on the axiom display internals and
is queued behind the first two problems.

The low level task involves rewriting the front end to do I/O
thru the web interface instead of a pty, killing off sman, and
making the I/O controllable by spad code.



The goal is to have a working browser-based front end to axiom
that works on any platform or across the net by next year.

By design all of the C code disappears and all work is done
inside the lisp image. The actual functions will be implemented
at the axiom/spad language level so that users can have complete
control of I/O directly in spad. 

So the overall redesign calls for a lisp-only, browser fronted
axiom which uses html (maybe mathml, undecided), javascript and
a general browser (or any network program). All of the C code dies.
All of the hyperdoc language/machinery dies. Sman dies. All axiom
code is just a single lisp image.




Problem 4 is to move on to making the front end and back end
reflect the crystal/facet design. More about that when the first
3 parts begin to work.




Design suggestions and discussion are welcome.

Tim