Kaleida Labs

Announced in 1991, the company began operations in the summer of 1992 with Nat Goldhaber serving as its first CEO.[1] The company was staffed by hand picking members of Apple's QuickTime team, along with members from the big-iron content delivery side at IBM.[2] Kaleida's corporate offices were located in Mountain View, California, at sites near the Shoreline Amphitheater on the east side of U.S. 101. Kaleida was one of the earliest companies to post a corporate website.

The early model for the system was the Kaleida Media Player, or KMP. This was essentially a cross-platform interactive version of the QuickTime Player that would run on the Apple Macintosh, IBM PC clones, as well as set-top boxes and other platforms. It was intended to be a single universal multimedia system.[2] On top of this model was the ScriptX programming language and object library, which allowed developers to make the media files completely interactive.

According to statements made at the Digital World Conference, Goldhaber stated that ScriptX would allow developers to distribute their work on practically any device simply by “hitting a button on a screen and selecting ‘Save as ScriptX’."[3] Grandiose statements were typical, with Goldhaber later stating that "It actually does have some genuine social importance."[4]

Goldhaber's flamboyant style, expensive company payroll, and lack of obvious progress led to negative stories in the press. One executive who described that "the company has spent about $20 million in its one year of existence and that Apple and IBM are loath to continue spending money at that rate. He said Kaleida salaries are high and that the company has too many employees for its current stage of development".[5]

In early 1993, Goldhaber and the board started fighting over stock options and whether the company should go public. On July 18, 1993 the company announced that Goldhaber was being replaced as CEO by Mike Braun, formerly of IBM. The company stated that Goldhaber would remain on the board in efforts to build industry partnerships, but blamed a lack of progress on this front, and Goldhaber's "hands off" management, as the main reasons for the switch.[6] In parting, Goldhaber quipped that different cultures and political maneuverings at IBM and Apple doomed the company from the start.[2]

Following Goldhaber's ousting, the company’s focus was narrowed. Plans to build a system for set-top boxes was officially abandoned in April 1994.[7] Kaleida’s mission from then on was to complete and support the ScriptX language and multimedia object library, which by this point were very late. Kaleida sought to bundle the KMP as system software with new personal computers. At the same time, CD-ROM developers could ship the KMP with content to support existing Windows and Macintosh systems. As part of the new focus, the company was downsized, with layoffs representing about 20 to 25% of the workforce.[7][8]

In late 1993 and early 1994, the company’s objective was for the Kaleida Media Player to run on a reference platform consisting of either a 25 MHz Motorola 68030 or a 25 MHz Intel 80486 processor running with 4 MB of random access memory. Such a system was typical of the installed base at that time, and most new computers were shipping with a read-only CD-ROM drive. Toshiba, which had supported Kaleida’s set-top box effort, became a minority stakeholder. Throughout its brief history, Kaleida maintained cross-platform development efforts for Windows (both Windows 3.1 and Windows 95), the Macintosh (supporting both the 68000 and PowerPC platforms), and OS/2.

The ScriptX development kit and the 1.0 version of the Kaleida Media Player were finally released on December 19, 1994, now considerably late.[9] Nevertheless, reviews were generally positive, calling it "remarkable for its ease of use" and stating that the core "classes that provide a high common denominator feature set for ScriptX-based development".[10] However, performance was another issue entirely. The 1.0 version of the KMP required 3.3 MB of RAM on Windows and 2.9 MB on the Mac, and this was for the basic runtime only, not the actual content that ran on it.[10] To put this in perspective, a mid-range Mac of the era was the LC 475 which shipped with only 4 MB of RAM standard, of which the OS used a significant amount. Moreover, the system was not released in PowerPC format, although by this point the PPC had already formed the high end of the Mac lineup for eight months.[10]

Kaleida had been founded partly as an authoring environment for applications based on CD-ROMs. But the product life cycle of CD-ROMs, which had been heralded for years as a content delivery system, turned out to be surprisingly short. By 1995 it was becoming clear that the World Wide Web would be delivering many of the lightweight interactive systems that were previously delivered in CD-ROM, and while video and similar high-bandwidth systems were not yet suitable for the Web, they did not need the development environment or interactivity offered by something like Kaleida.

Kaleida had also been formed, to some degree, to offer an alternative to the Wintel platform for what at that point appeared to be an emerging market in the CD world. Goldhaber had mentioned this on many occasions, describing the upcoming "war" for multimedia.[3] After Netscape's public offering early in 1995, many software developers recognized that the browser itself would pose a challenge to Windows, and that the browser would become a multimedia platform in its own right. The standalone platform to attack Wintel now existed. Kaleida then started an effort to deliver objects over the Internet and deliver Web content.[11]

Most potential Kaleida developers had been taking a wait-and-watch approach to the system, waiting for Kaleida to solve performance problems and ship a more stable version of ScriptX. However, the company had not been able to demonstrate a system that ran acceptably in less than 16 MB of RAM, which was at that time the "high end" of the market. Macromedia's Director and associated Lingo program took advantage of the vacuum to establish a strong market.[12] Meanwhile, Sun Microsystems was promoting its new Java programming language as a Web-dedicated system designed specifically to run on even the smallest platforms.

By late 1995 it was clear that ScriptX had lost its momentum in the market, even though the company was on the verge of shipping ScriptX Version 1.5. In November 1995, Apple Computer and IBM announced the closure of Kaleida Labs, effective in January 1996.[13] The parent companies announced that they would ship ScriptX 1.5 anyhow. Future development of ScriptX would move to a group inside Apple Computer, and Apple offered jobs to most members of the ScriptX engineering team.

ScriptX Version 1.5 shipped almost concurrently with the closure of Kaleida Labs, in January 1996.[12] By shipping ScriptX, Apple and IBM met contractual commitments they had made to developers and avoided legal difficulties. Ultimately, only two multimedia content projects ever shipped using ScriptX 1.5. One was a CD-ROM version of the Swedish National Encyclopedia, Nationalencyklopedin, developed by Linné Data of Gothenburg, Sweden. The other was an interactive music title, Robert Winter's Crazy for Ragtime.

Within a few months, development of ScriptX withered away inside Apple, and the remaining employees had either migrated to other jobs at Apple, or had left for other companies in the industry. The Director application remained a major force in the multimedia market for a time, but was supplanted and then replaced, by Flash. Early versions of Flash are in many ways a clone of ScriptX, using a small plug-in runtime with an event-driven language and similar resource requirements.

The principal software architect of ScriptX was John Wainwright, an Australian-born computer scientist. ScriptX was implemented in C, using an extensive library called Objects in C that Wainwright had developed before joining Kaleida, and sold to the company at its inception. Objects in C used preprocessor directives to simulate an object system within the libraries. The library featured more than 240 classes, many of them designed to support multimedia as well as create customized user interfaces. Common data structures such as arrays and linked lists were implemented as collection classes in the library.

ScriptX was an object oriented scripting language, which used design elements from "Smalltalk, Dylan, Hypertalk, Lisp, Object Logo, C++, and Pascal".[14] With Smalltalk, it shared the concept of classes, objects, and inheritance, but also featured multiple inheritance in both classes and objects, and dynamic binding of objects at runtime. ScriptX had no primitive data types; even integers were defined as objects. All objects were instances of a class, and classes themselves were instances of a MetaClass object. As in LISP, there were no statements, and every line in a ScriptX program was an expression that returned a value.[14]

ScriptX used garbage collection running in a separate thread to handle memory, and featured an object store for permanent collections. ScriptX supported multi-threading but not multiprocessing, and offered scripting control of lower level operating system features such as events and concurrently running threads. Early multimedia development tools lacked techniques for synchronizing presentations, except by polling the operating system's own clock. Ray Valdés, writing in Dr. Dobb's Journal, noted that, "a key ScriptX feature is a Clock class, which provides facilities for synchronizing timed sequences of actions required by multimedia apps."[14]

Following the closure of Kaleida Labs, Wainwright went on to serve as the principal architect of MaxScript, a scripting language for 3D Studio Max that has been used to process content for gaming and 3D applications such as the Maxis Sims programs.[15] Thus, ScriptX can be considered a progenitor of MaxScript, which closely resembles ScriptX.

The following code illustrates the unique syntax of the ScriptX language. It is part of a class that handles mouse tracking in a larger program written by Don Hopkins.[16]

-- The sendTrackDrop method sends a trackDrop message to another object. 
method sendTrackDrop self {class Tracker} service target x y data doit -> (
 	local coords := new Point
	repeat while (true) do (
		if (canObjectDo target trackDrop) then (
			return (trackDrop target service x y data doit)
		) else (
			coords.x := x
			coords.y := y
			local t := findFirstAtPoint target coords
			if (t == empty) do return false
			x := x - t.x
			y := y - t.y
			target := t
		)
	)
 )

This code is responsible for forwarding trackDrop messages between objects, and illustrates a number of uncommon features of the ScriptX language. Of minor note of interest is the := assignment operator, like that of Pascal.

Variables are marked local to determine their scope.[14] This is the opposite of most modern languages, where "local" is the default scope, and such a declaration would be redundant. In conventional languages the scoping visibility is defined by the location in the source code file - variables declared inside a method are local to that method, those defined outside methods or other declarations are global to the class (or program).

This lack of file-based scoping is a base feature of the ScriptX language and others like it, notably Dylan. In conventional languages like Java, classes and similar constructs are defined within a single file, or at least a "master file". Scope is defined by the file system and the code's location within it. In contrast, in ScriptX any method can be defined on any class in any file. In this example, the method sendTrackDrop is being applied to the Tracker class, and can be placed within any file that will be accessed during runtime. This allows programmers to organize their code by class or by functionality, at the cost of some extra syntax.

Java has many similarities with ScriptX. Like ScriptX, it is an object based language with elements of syntax that are similar to C and C++. Java classes support a limited form of multiple inheritance through interfaces, and the Java runtime environment utilizes a garbage collector for memory management with a "tracing" architecture similar to that of ScriptX. Both Java and ScriptX translate programs into a platform-independent bytecode.

Unlike ScriptX, Java is not a pure object system, and has primitive data types. In contrast with ScriptX expressions, Java programs are always written inside a class definition, and return either a value or void. This makes Java code much easier to secure, to protect from tampering and malicious interference. Java was able from the beginning to support multi-processing as well as multi-threaded applications, and thus was naturally scalable. These features, and other attributes of Java, made it more suitable for a distributed and networking environment than ScriptX.

Although both ScriptX and Java were designed as platform independent virtual machine environments, their philosophy and implementation were quite different. The Kaleida Media Player was a complex interpreter that required several megabytes to run, and Kaleida never achieved effective performance on a system with less than 16 MB of random-access memory. By contrast, Java was designed to run compiled bytecode on a stripped down virtual machine that could be implemented on virtually any 16-bit or larger processor. In this way, Java could be used anywhere from handheld devices or consumer appliances to mainframe computers.

In 1995, Java was being demonstrated mostly as a runtime environment for small applets, as code that could be embedded in web pages and downloaded to run in the browser. Sun Microsystems provided detailed specifications for Java, released many classes in open source, and aggressively formed alliances to distribute it and share its development with other companies throughout the computer hardware and software industries.