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 _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
