we're debating, not disagreeing. although you're clearly wrong :-) i agree standards are a *good thing*(TM) but standards come after practice, not before. when they come before practice they are generally large, expensive, and overbuilt (e.g. XML)
i agree that browsers are a good thing. they are platform independent, use standards, and allow marvelous things to happen. or not. in particular they explicitly do not allow themselves to be used as a useful front-end for local programs. i agree that we don't want to re-invent the world and that we want to follow standard practice. However i disagree that we should work solely within standards. what i see us doing is using cheesey work-around languages like javascript and badly designed data structures like DOM. we're going to end up with (a) a program that is "more of the same" (b) is in a hard to maintain language that isn't very portable (c) hamstrung by the standard-per-browser problem (d) encoding our information in latex -> XML -> javascript hacks (e) unable to "really communicate" with the user thru the browser (f) bending the world to fit the doorway (g) unable to start local programs, save state, really interact think about what we want. we want a portable front-end to axiom that we can extend in various ways to do truly cool NEW things. we want the end user of axiom (the spad programmer) to be able to make the front-end do truly cool NEW things. we want our documentation (pamphlets) to be magic drag-and-drop, clip and execute, inline moving graphics, managing multiple programs like axiom, our graphics, ACL2, and other tools. We want to be able to save state back into a representation that axiom and the front-end can both use. current browser technology won't allow us to "extend" it in various ways (such as making one of the tabs be an axiom shell session). it won't read and write pamphlet files (inline latex, inline chunks). it won't allow drag-and-drop of pamphlets. it can't start or manage local programs. it can't handle giving up screen real estate as canvas areas. it can't write to the file system, etc. yes, you can do some of those tricks with acres of javascript, special certificates, plugins, cookies, and other hacks. but think of all of the code you have to write in javascript, html, xml, C, etc. it will only get MUCH worse as you try to write javascript to read the semantic network problem data structure and render the appropriate html. javascript is a horrible language and we have two great languages (spad and lisp). i'd agree with your approach if we could do something like graph the algebra hierarchy without a ton of java and a plugin or draw a graph on a tab from lisp. i can almost envision the C code necessary to start axiom (or some other program) from the browser, hand it the screen area of a tabbed pane, and present an API from the browser code to draw. if it is 1000 lines i'd be astonished. all the cross-platform work is already done. use the browser, keep the standards. but extend the tool to do what you want. i don't change GCL, i simply extend it to be useful. i don't change noweb. i simply add functionality i need. we won't change the browser, we just need to extend it to be useful. think of the browser as having solved the cross-platform problem and as a large library of useful code. now we want to make it sing and dance to our new ways of thinking. we still do what a browser does (we have the same base code) but we do so much more. t _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
