I wrote this in 1995, at Kaleida Labs. The web was so new and exciting back then!
ScriptX and the World Wide Web
"Link Globally, Interact Locally"
by Don Hopkins, Kaleida Labs
Benefit of ScriptX to Web BrowsersThe World Wide Web is an excellent way to distribute cross-platform interactive multimedia ScriptX objects. The Kaleida Media Player, running on net-surfing Mac and Windows platforms, can dynamically load in and plug together objects from "title containers" transferred over the web.
ScriptX title containers are portable files containing ScriptX objects, code and media: text, images, animation, sound, MIDI, music, movies, and modular object-oriented programs that plug together dynamically to orchestrate open-ended interactive multimedia experiences.
You can publish self-contained multimedia ScriptX titles (i.e. applications, tools, games, catalogs, presentations, documents), as well as reusable ScriptX objects (i.e. modular components, accessories, characters, places, clip-art, plug-ins, SimProducts), so people can download the ones they want, and compose and interact with them locally, on their own computers.
Web browsers such as NetScape can be configured to use the Kaleida Media Player (KMP) as a "helper application", so it's simple for people with NetScape and the Kaleida Media Player to download and interact with ScriptX objects: just click on a link to a title container, and it's distributed over the network and dynamically loaded into the Kaleida Media Player, where it comes to life!
ScriptX Pizza DemoThe ScriptX Pizza Demo, at "http://www.kaleida.com/official/pizza", lets you construct a pizza by plugging together ScriptX objects from several title containers delivered via the World Wide Web. First you select a pizza crust in one title container, then you can select any number of pizza toppings in separate title containers. They're dynamically loaded into the KMP and locally composed in a window, that you can interact with by dragging the toppings around on the crust. There's even a "big brother" spinning eyeball topping, that animates as you move your cursor around the screen!
This demonstrates network distribution of cross platform code and media, with local interactivity, direct manipulation, animation, dynamic binding, and plugging together objects from different containers.
There is an extension to ScriptX on the Mac that enables it to ask NetScape to open any URL, so ScriptX can cause NetScape to display a web page, load another title container, and even send messages to interactive web services (like submitting an order for a pizza).
ScriptX Web developers will go far beyond mere pizza toppings, publishing innovative interactive experiences on the network, no longer limited to the static text, graphics, and forms of HTML.
Benefits of ScriptX to Web DevelopersAs a general purpose object-oriented multimedia scripting language, ScriptX has many uses for web developers. It can import and export various file formats, index, search and manipulate multimedia databases, automatically generate HTML from macros and templates, draw and composite images and produce corresponding image maps, and serve as an open ended programmable hypermedia synthesizer.
For example, the ARPANet Map, at "http://www.catalog.com/hopkins/arpanet/index-large.html", is a web of html, gif images, and image maps, all synthesized off-line by ScriptX from an abstract topological graph of the network.
Future DirectionsAs described above, there are many interesting things that can be done by distributing files generated off-line by ScriptX, including title containers, HTML pages, images, and image maps. This can be taken much further by using ScriptX as an interactive on-line web server, synthesizing distributed hypermedia on demand!
There is an experimental extension to ScriptX on the Mac that enables it to be used with MacHTTP as a "Common Gateway Interface" server. It's possible to link to a running ScriptX program, that dynamically interprets URLs and forms results, and generates responses on the fly.
ScriptX can produce and respond to web pages with forms and pictures (buttons, scrolling lists, text fields, and clickable images), that most web browsers support. We have developed an experimental framework of classes for generating HTML from ScriptX objects, and programming interactive Web services with forms, macros, and high level HTML widgets with clickable images. It's possible to implement image maps that send events directly back to the ScriptX presentation and model objects that rendered them. Example web services that have been implemented with this framework include class and generic browsers, and a scrolling zooming image browser.
ConclusionScriptX deeply satisfies an important unfilled niche in the World Wide Web: it makes it possible to implement and distribute high quality cross platform interactivity, far beyond the static HTML forms and text formatting capabilities of current Web browsers. In the long term, ScriptX is the ideal framework for developing open-ended, extensible Web servers and browsers, distributed hypermedia authoring tools, multi-user colaborative online services, and compelling online store fronts, games, and educational experiences unlike anything that's been done before!
Here's some interesting stuff about the design and development of Relax NG:
James Clark wrote about maximizing composability:
First, a little digression. In general, I have made it a design principle in TREX to maximize "composability". It's a little bit hard to describe. The idea is that a language provides a number of different kinds of atomic thing, and a number different ways to compose new things out of other things. Maximizing composability means minimizing restrictions on which ways to compose things can be applied to which kinds of thing. Maximizing composability tends to improve the ratio between functionality on the one hand and simplicity/ease of use/ease of learning on the other.
Clark describes the derivative algorithm's lazy approach to automaton construction:
I don't agree that <interleave> makes automation-based implementations impossible; it just means you have to construct automatons lazily. (In fact, you can view the "derivative"-based approach in JTREX as lazily constructing a kind of automaton where states are represented by a canonical representative of the patterns that match the remaining input.)
The Relax NG derivative algorithm is implemented in a few hundred elegent declarative functional lines of Haskel, and also in tens of thousands of lines and hundreds of classes of highly abstract complex Java code.
Clark's Java implementation of Relax NG is called "jing", which is a Thai word meaning truthful, real, serious, no-nonsense, and ending with "ng".
Comparing the Java and Haskell implementations of Relax NG illustrates what a wicked cool and powerful language Haskell really is. The Java code must explicitly model and simulate many Haskel features like first order functions, memoization, pattern matching, partial evaluation, lazy evaluation, declarative programming, and functional programming. That requires many abstract interfaces,, concrete classes and brittle lines of code.
While the Java code is quite brittle and verbose, the Haskell code is extremely flexible and concise. Haskell is an excellent design language, a vehicle for exploring complex problem spaces, designing and testing ingenious solutions, performing practical experiments, weighing trade-offs, and writing succinct, elegant, mathematically rigorous specifications that actually work. Haskell code is useful as a blueprint for implementations in less luxurious languages like Java.
In The State of XML, Edd Dumbill explains the secret behind the success of Relax NG:
Incidentally the RELAX NG success can equally well be framed as a case of design-by-inspired-individuals vs. design-by-committee as much as it can be seen as a OASIS vs. W3C thing.
James Clark is a fucking genius! He’s the guy who wrote the Expat XML parser, works on Relax NG, and does tons of other important stuff. Relax NG is an ingeniously designed, elegant XML schema language based on regular expressions, which also has a compact, convenient non-xml syntax.
I totally respect the way he throws down the gauntlet on operator precedence (take that you Perl and C++ weenies!):
There is no notion of operator precedence. It is an error for patterns to combine the |, &, , and - operators without using parentheses to make the grouping explicit. For example, foo | bar, baz is not allowed; instead, either (foo | bar), baz or foo | (bar, baz) must be used. A similar restriction applies to name classes and the use of the | and - operators. These restrictions are not expressed in the above EBNF but they are made explicit in the BNF in Section 1.
You can translate back and forth between Relax NG's XML and compact syntaxes with full fidelity, without losing any important information. Relax NG supports annotating the grammar with standard and custom namespaces, so you can add standard extensions and extra user defined meta-data to the grammar. That's useful for many applications like user interface generators, programming tools, editors, compilers, data binding, serialization, documentation, etc.
The schema starts out by defining a few namespaces:
default namespace = "http://www.laszlosystems.com/2003/05/lzx" namespace rng = "http://relaxng.org/ns/structure/1.0" namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes" namespace lza = "http://www.laszlosystems.com/annotations/1.0"
The a: namespace defines some standard annotations like a:defaultValue, and the lza: namespace defines some custom annotations private to the Laszlo compiler like lza:visibility and lza:modifiers. Thanks to the ability to annotate the grammar, much of the syntax and semantics of the Laszlo programming language are defined directly in the Relax NG schema in the compact syntax, so any other tool can read the exact same definition the compiler is using!
To show how truly simple and elegant it is, here is the snake eating its tail: The Relax NG XML syntax, written in the Relax NG compact syntax:
Laszlo Mail is a rich web email application that runs in any web browser on any kind of computer with the Flash player. It's written in OpenLaszlo. Earthlink is deploying Laszlo Mail to their customers, and Laszlo Systems has released this demo version for free on their own servers. Give Laszlo Mail a test drive -- be sure to check out the contact details, search interface, the wysiwyg email editor, spelling checker, and how the user interface adapts as you resize the window. You'll see why I'm so excited about OpenLaszlo!
I worked on Laszlo Mail for Laszlo Systems as a contractor, developing the drag-and-drop email folder tree, and also the attachments upload component, so I'm biased of course. I'm applying what I learned by working on Laszlo Mail to developing my own Laszlo applications. I like OpenLaszlo because it's open soure, really fun to program, supports full-blown user-friendly rich graphical interfaces, and scales up well to handle heavy duty tasks like reading email.
Here's an interesting audio interview with Dave Temkin, CTO of Laszlo Systems. They cover some important topics and Dave makes some great points that explain why OpenLaszlo is so exciting.
They discuss why Laszlo was open sourced, why open source software is so important, what the ideas behind Laszlo's design are, why Laszlo uses Flash, how it actually operates at a higher level independent of Flash, what the technologies that led to the Laszlo application language were, how Laszlo integrates open standard technologies, how it relates to AJAX and DHTML, which companies and applications use Laszlo, which software development tools support Laszlo, how the user base is growing now that it's open source, what kinds of reusable components and widgets are Laszlo Systems developing, what opportunities exist for web developers and user interface designers, and where Laszlo is headed in the future.
There's a lot I like about OpenLaszlo. It has all of the advantages and none of the problems of the NeWS Window System, which was a technological success that failed because it was proprietary. I was daydreaming about having a system like Laszlo in 1998, and while I was intrigued by Flash, I avoided it for all the obvious reasons. But nothing can hold a candle to Flash's market penetration, graphical quality, and consistency across platforms.
The important thing about OpenLaszlo, which will ensure its long term success, is that it doesn't lock you into the Flash player, even though it takes advantage of Flash as a standard ubiquitous runtime. Laszlo is abstract from the Flash player, and it will output to other platforms over time as they mature, such as DHTML, Java and .NET.
The interview is an audio "podcast," and there's no text transcript available, but here's the blurb about it:
David plans to leverage rich client environments other than Flash Player, such as DHTML, Java and .Net and shares his about thoughts about Eclipse, the recent Adobe/Macromedia merger, refactoring the desktop user interface and calendar interoperability. He also explains why Flash is not an ideal platform for mobile devies and desktop applications and compares Laszlo Blog Boxes to widgets in Apple's Dashboard and Yahoo's Konfabulator.
Today, Grig and I were discussing how to evaluate arbitrary mathematical expressions in Laszlo applications, in the absence of "eval".
I think it would be easy to implement a simple rpn stack machine like PostScript, that used string.split(" ") to break a string apart into tokens, which Flash can do fast.
So I hacked up this Laszlo interpreter class that behaves almost but not quite completely unlike a PostScript interpreter.
This is the documentation for the OLE Automation Interface to Transmogrifier (version 2.1.2 and greater).
This is an essay written a while ago (1986 or so) by Richard M Stallman (RMS), about his experiences at the MIT AI Lab, and the story of the Lisp Machine Wars.
Machine Room Folk Dance, Thursday at 8pm.
Come Celebrate the Joy of Programming,
with the World's Most Unbureaucratic Computers.
(There were only five of us dancing, but we had a good time.)
My first experience with computers was with manuals for various languages that I borrowed from counselors at camp. I would write programs on paper just because of the fascination of the concept of programming. I had to strain to think of what the programs should do, because I had nothing to supply me with a goal except that I wanted to program. I wrote programs to add up the cubes of a table of numbers in several assembler languages at various times.
The first actual computers I met were IBM 360's, at the IBM New York Scientific Center, when I was a student in high school. There I quickly developed interest in language design, operating systems and text editors. Hired for the summer to write a boring numerical analysis program in Fortran, I surprised my boss by finishing it after a couple of weeks and spent the rest of the summer writing a text editor in APL.
I also quickly manifested a lack of proper reverence for authority. The whole center had been denied access to the IBM computer in the building, and we had to use slow telephone connections to the Cambridge Scientific Center. One day an IBM executive came to tell us about the work various IBM scientific centers were doing, and finished with, "Of course you all know the important work being done here." I asked him, "If our work is so important, why can't we use the computer in this building any more?" After the meeting, my friends told me they had wanted to say such a thing but were afraid of reprisals! Why? Certainly nothing happened to me as a result. They seem to have learned the habit of cowering before authority even when not actually threatened. How very nice for authority. I decided not to learn this particular lesson.