[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] axiom, browsers, and crystal

From: daly
Subject: [Axiom-developer] axiom, browsers, and crystal
Date: Mon, 20 Jun 2005 18:35:08 -0500

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]