Kaleida Labs ScriptX
Index: Requirements
Problems Companies
Platforms Languages
Software Research
- Kaleida's cross platform object oriented multimedia scripting language.
- Runs on MacOS, Windows,
and OS/2.
- Kaleida was shut down and ScriptX was absorbed into Apple.
- Streams
- Unfortunatly have a built-in iterator.
- Can't play two parts of a movie at once.
- Collections
- Iterators
- Search engine
- Fancy but dropped because it wasn't being used by developers.
Too hard to understand. Didn't do everything a real database would do.
- The actual implementation of the abstract search engine protocol
in ScriptX didn't ever quite do enough fast enough, but it might have been
a good object oriented interface to remote databases of different types,
had we gone through with that part of Distributed ScriptX. The search engine
was eventually removed from ScriptX to get its size down, and replaced with
a simple text searching context object, more appropriate to the needs of
our developers.
- The collection protocol is mixed into many other parts of the system,
like the presentation hierarchy. This makes manipulating nested graphics
easy once you know how to manipulate collections, which is supported by
the language in many ways.
- Indirect collections
- Implements the collection protocol by delegation to a target collection
of another built-in class. Exposes the union of the collection protocol
so as to factor out the collection behavior of its target from the target's
other behavior, and translates the higher level methods (like addMany) into
the lowest common denominator methods (like several addOnes), so you can
use different types of targets for different situations, as efficiency or
convenience dictates, without changing the code that uses the IndirectCollection.
Maybe it should be smarter about looking at the class of its target and
not wasting its time breaking down higher level operations that the target
supports, since it does restrict the target to being a built-in type.
- Class system
- Modules
- Garbage Collector
- Object store
- The object store uses the metadata to automatically flatten and
inflate objects to storage on disk, and uses proxies that page their bodyies
in on demand. When you send a message to a proxy of an object that hasn't
been loaded, it's inflated, and the original proxy handle is stomped on
to be an indirect proxy to the real object handle. When you are done with
the object (like a bitmap), you can call makePurgeable on it, and the proxy
target will be garbage collected from memory, and not reloaded from disk
unless you send the proxy another message (you can keep ahold of the proxy
after the call to makePurgeable, it's just its body that will be garbage
collected.) When you page in an array, the objects inside the array are
not automatically loaded until you touch them, and you can shake them out
of memory with makePurgeable until you need them again. (That does not write
out any changes).
- Meta data
- Metadata describes the layout and meaning of data in memory.
- Used by the garbage collector as well as the object store, to describe
class and instance variable layout, as well as substrate level C structures.
- The object store uses the metadata to automatically flatten most
of the objects and classes. Classes can define methods to manually flatten
and inflate parts of themselves as well, but that is only needed for special
cases.
- There is a metadata compiler that compiles this extended C struct
declaration language into C and header files, containing the metadata, as
well as the "macrology" necessary to implement the object system.
- Loader
- The loader dynamically linked libraries against exported ScriptX
symbols, so you could call into most ScriptX functions and generics quite
easily. This of course exposes all of ScriptX, even more intimatly than
the Premier plug-in exposes Premier. ScriptX
dynamically loaded libraries can use the names of classes, generics, and
global variables, as well as substrate level C structures and functions.
But what is not exposed to third party libraries is the header files that
implement the ScriptX class system, OIC (Objects In C). These complex and
proprietary "macrological" header files of are needed in order
to actually *define* a new class, as opposed to merely using a pre-defined
substrate or scripter level classes and instances. Internally at Kaleida,
proprietary libraries like the DTK (the Director importer toolkit that actually
used M5 and some licensed and modified Macromedia
code) that need to define their own classes, are built in the main source
code tree so they have access to all the header files they need. While there
are a lot of things third parties can do by writing dynamically loaded libraries
to plug into ScriptX, just by implementing some primative functions, it's
desireable to wrap a ScriptX class around code. It's possible to do this
by writing ScriptX code that defines a class to wrap around the primitives,
that loads the library when the first time it needs to, and whose methods
call the primitive and handle argument conversion, error checking, exception
handling. Lots of this can be automated, driven off of some simple ad-hoc
meta-data. But in the case or wrapping dynamically loaded primatives with
ScriptX classes, the ScriptX code must loaded before the library. This is
ok in many cases, but *not* in the case of importers and exporters. Importers
and exporters are called by the ImportExportEngine when somebody wants to
convert back or forth between a flat stream (like a wave file) and some
higher level built-in media object (like an AudioStream or AudioPlayer).
The ImportExportEngine uses the loader to try and find the library in a
certain directory. The protocol of the ImportExportEngine with the shared
library is that it requires the entry point to return a ScriptX class, a
subclass of the appropriate abstract Importer or Exporter. But the whole
point is for the C code to implement that subclass of Importer or Exporter.
Third party code is not allowed to define their own classes. The best it
can do is to call back into the ScriptX interpreter somehow, and cause that
class to be defined. Third parties can easily define primitives that can
be bound to methods of the class, and probably even bind the methods to
generics themselves, but not make the class itself. There has to be some
ScriptX code somewhere that does that, or a Kaleida supplied library or
function to call that can be used to make a new Importer or Exporter subclass,
but there isn't. (I kind of wish they'd been able to fix that before the
release.)