taking this discussion away from the short term summer of code so we can think about the bigger issues.....
in the long term (the 30 year horizon) it seems clear that some sort of browser-like capabilities are assumed. the limitations we have now seems to be things like: * the syntax of the web page does not have a semantic model we're trying to build a research science platform, not a display GUI object. we'd like the GUI piece of the system to have a clean, programmable semantics so we can reason about user actions. we want to reflect user actions (say handwriting, gestures, clicks, eye-gazes) and system state (say branch cut crossings, solid model data structure stresses, hill climbing search progress, as subtle changes to the screen. Think of a search space program that does hill climbing (or root finding, or ...) that presents it's current state on the system. The user gaze shifts to various areas and the gaze tracking hardware gives us a vector for a direction to explore. * the DOM model is hierarchical the DOM is a Document Object Model. it's basically a hierarchical data structure and it suffers from the same problems that databases used to suffer, that is, the hierarchy. Hierarchical databases ruled the day until new theory came around and the world went relational (I know most of you don't remember it but there was a HUGE fight about this. I attended a committee meeting about this at a database conference and the major objection was there would never be enough horsepower or memory to handle relational searches... beware the future). * the DOM model is not really math-aware i'd envision the DOM being a surface-level representation of the actual data structures used. the DOM would be available in one of the facets of the crystal, possibly to support old browsers. there are much more useful and efficient data structures for representing problem spaces, state spaces, and system state. * the browser cannot interact with the filesystem * the browser pages cannot be drawn upon * the browser pages are "paper-like" the browser is a dumb tool at the moment. we need to break out of the mold, pick a particular browser, and make our own version of it. our version can be modified to do read/write of the file system, handle socket connections, present tabbed pages or sub-areas as an active canvas so Axiom can write graphics or text to them in real time, present a section of the screen as command-line I/O, show axiom state in special tabs, allow the browser to start axiom, let it speak lisp, etc. in short, we need to stop struggling with the limits of current browser technology, take a standard browser and extend it to our purposes. in fact, i expect we could do what we do with GCL: package our own version from a tgz file and add patches to do what axiom needs. in the 30 year horizon we need something that is useful, impressive, and reasonably modern. today's tools just hint at what will be common. we need to listen to the hints, anticipate the needs, and get out in front. the term i've been using is a "crystal" which is an object with many facets that "floats" around a central problem description in its own representation. we need to think about the researcher's problem space in a much deeper form than current systems do (including Axiom). in the long term we want to be at the center of the tool set that researchers use to solve problems. research is long-term, detail-tedious, and takes a lot of work to build up a big picture. we want to be able to capture problem state, suggest relevant papers, perform proofs in the background, do speculative computations for possible suggestions, pre-generate literate pamphlets with references and code, etc. we want to draw a wide range of tools together (math language, graphics, 3D models (organic, engineering, etc), full-text searches, collaborative tools, etc). related to the current suggestions i think we are limiting ourselves too much and creating too tight a straight-jacket by trying to work within the limits of current browsers and MMA-like worksheets. choose a browser, get the source, add it to axiom, and extend it in various ways so we can experiment with ideas. just making it possible for the browser to read/write the filesystem and present a "canvas" area to axiom puts us far ahead of the world. it's not ideal but it works. t _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
