Martin, Sorry for the delay in your question about working together on the hyperdoc issue. I've been giving it some thought. I have a long term view of the "porting problem" which might be different from your (or anyone else's) view so this is purely my opinion. I'd welcome feedback on it.
For me the current hyperdoc is "so last year". The issue is not that it uses old-looking technology. Hyperdoc shows a lot of the features found in current browsers and was way ahead of its time. However, I want to do things now that are "way ahead of their time" so that 30 years from now the complaint will be that the world has finally caught up. There is the fundamental design issue, which I've been calling the "Crystal" problem. It involves a multi-faceted view of a single unified core problem. Lets ignore the deeper issues of the embedded semantic network, the "intentional stance tracking", etc and just focus on the low-level technology issues. I've been doing isolated "experiments" to try to test these tools to see what they can now do and find things they still need to do (e.g. the lisp replacement for javascript does not yet do <canvas>). The experiments are simply learning exercises to try to find the limits of what the current tools do. But there are some low-level goals that lie behind these exercises: END-TO-END-LISP I see the lisp as the base of axiom all the way to the base of the web browser. End-to-end lisp is important because it gives me a lot of power with very little work. I can dynamically create executable expressions that can be evaluated in the browser and/or in the axiom image. With tools like Hunchentoot I can map URLs directly into lisp function calls. This means that I can dynamically create pages and hyperlinks and have them execute function calls. Thus URLs can be created to directly execute algebra, to dynamically create hyperdoc pages, etc. <http://weitz.de/hunchentoot> With Kamen Lisp (which replaces javascript in the browser) I can dynamically upload/download lisp functions. I can remotely manipulate the document structure. I can communicate between multiple tabs so that one tab can have the "worksheet" and another can have an axiom workspace where I try axiom expressions. I can have multiple browser windows communicating with each other so that I can manipulate a graphics object in one window (e.g. rotate, scale, subset, etc) and have the corresponding expression show up in another window. <http://www.cs.stevens.edu/~dlong/software/kamen/index.php> With Apache I can configure it to talk to lisp and axiom directly <http://www.accela.net/~dankna/guide.html> Thus I can have apache manage the connections. If Axiom is configured to sit directly behind apache I have the option of having each browser tab be a separate axiom session, or the tab could have its own workspace (axiom supports multiple workspaces) or I have have them all share a session. Indeed I could have a tab open to an axiom running on a different server entirely. BROWSER DOES GRAPHICS A near term goal is to lift the graphics out of the C code and into lisp. Once this is done the graphics can be dynamically manipulated by lisp and lisp can be dynamically manipulated by the graphics. Thus the algebra code can interact directly with the image allowing things like continous rotation (lisp drives the graphics) or have data from the graph be transmitted back to the algebra (e.g. picking the endpoints of the domain of a function, deciding control points of inflection, interactive root finding, etc). This opens the way for doing things like solid modeling where I can use Axiom to compute the stresses and strains in the model where it takes input from forces applied by the user. I can manipulate strings of primitive objects (folding, twisting, attaching) to shape objects which know how to self-assemble since I can keep the operations in a data structure parallel to the graphics. Replaying the data structure on a primitive string re-folds the object. The tools to do this are the <canvas> tag and Kamen lisp on the front end and a lisp-based graphics/algebra connection on the back end. I also see a tighter connection between the graphics and the axiom data structures. So if I create a complex graph object (such as the dependency graph of the algebra) I can see the graph object drawn directly from the algebra. If I implement a "cost" primitive it would be possible to compute the cost of a computation and show the computational costs of an algorithm on the graph. Geometric objects (sheaves, splines, manifolds) can be visualized an manipulated "visually" while the computation occurs in parallel symbolically. BROWSER DOES HYPERDOC Hyperdoc also needs to be lifted into lisp and made a more integral part of the system. Hyperdoc needs to know how to handle pamphlet files directly, that is, how to construct html from the pamphlet and pamphlets from input from the browser. This would allow the documentation to live in the pamphlet files. It would also allow dynamic documentation (e.g. new algebra domains recently compiled) to be shown. Since lisp has access to all of the algebra there is a wide range of searching capabilities that could be implemented (e.g. show all domains such that domain D has property P. The internal language of the documentation for Axiom is latex. The back end needs to know how to convert this to html (e.g. by using tex2html or some tool like it) and from html to latex. Further we need to think about things like MathML (I've done no experiments with this yet). BROWSER DOES FORMATTED I/O For the browser front-end to be useful in the long term we need to be able to manipulate the equations using tools like cut and paste. It should be possible to select a subset of an equation, clip it, or paste over it, and then see the computation repeated with the change. History needs to be easily manipulated. Web pages with results (e.g. as a notebook) need to be able to be exported as pamphlet files. The user should be able to use the browser as a complete front end, doing input, output, and interaction (e.g. such as graphics rotations which are sent back). It should be possible to visit other sites, clip an equation, and have it entered into the system. BROWSER DOES DRAG-AND-DROP It is important that we be able to take a pamphlet file, drag it onto the browser, and have it added to the system. This facility is fundamental to the idea that literate papers at a conference, or from a web publication, can be immediately added. The user should be able to do things like change the equations in the paper and see tables derived from the equation updated in real time. Bibliographic links should be fetchable in an ASDF or YUM-like form so that literate papers can reference other literate papers. Pamphlet integration is vital to the long term front end. FACETS Once we enter into the idea of the crystal we introduce the idea of a facet, which is a view into a piece of information about a unified problem. The facets are all connected, giving multiple views of the same problem while tracking the user's intentional stance. Facets are found by rotating the crystal. There's more but it takes us off into areas that only I care about (as if we're not there already) such as a semantic network problem representation and the interaction with the facets. I'm basically tracking toward the crystal idea and focused on the long term design. Thus I'm not spending a whole lot of time thinking about porting issues. I don't see porting issues as being fundamental in the long term view. I don't think the current design is sufficient to carry us much further into the future. Indeed it is hardly sufficient to carry us between platforms. I think it needs to be created anew. t _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
