Introduction

The Casbah System is to be a collection of protocols, technologies, and software parts which, at once, are tightly integrated and highly modular. Essentially, there should be as complete freedom as possible to use the tool which works best for the particular task at hand (for a given programmer) and to smoothly leverage one's mastery of The Casbah System. It is a fundamental design goal of The Casbah Project that The Casbah System, in so far as possible, never get in the way.

A crucial component of The Casbah System is the core application framework which provides a variety of high level services for the application builder. Simple and flexible access to Internet protocols, GUI widgets, XML processing, object serialization, data storage, content management, etc. are essential to a powerful, useful, and high quality application framework. The Casbah System will provide these services right out of the box (right out of the tarball?). However, it is impossible to anticipate every need or to provide such services in the most convenient way for every application. Thus, the core application framework of The Casbah System will be written in such a way to allow direct and straightforward modification, adaptation, and extension.

[Blah blah blah. This stuff belongs in a larger overview, if anywhere.]

What distinguishes the The Casbah System's core application framework from many other application frameworks is that what organizes the framework is not a feature of a language (i.e., inheritance) but of the datastore (Cairo/Coptic). One builds an application by "scripting" the datastore, which may directly contain values, provide mappings to remote data, and scripts--all accessible in a uniform and simple manner.

While The Casbah System defines various mechanisms for storing and manipulating values in the datastore (e.g., LDO, CORBA, etc.), it is important that the core application framework support rapid execution of stored scripts which, in turn, will typically call other stored scripts--all of which may be quite small and task specific. Since applications built on The Casbah System rely heavily on the core application framework, it will be a critical bottleneck.

Furthermore, the The Casbah System should be easy to browse, modify, and extend.

All this points to the need to closely couple the datastore with a language runtime or run times. There are several possible strategies:

1. One could couple multiple run times--one for each desired language. This option is clearly unattractive for its obvious cost in terms of speed, memory use, and pain of implementing the coupling.

2. Of course, one could simple couple a single runtime, and force the core application framework to be written in that canonical language. This is somewhat undesirable as it regulates all other languages to second class status, which undermines the ecumenical spirit of The Casbah Project. It's a choice we could make, if necessary.

3. However, when members of The Casbah Project considered which language they would favor as the canonical language, Python came up as the compromise candidate. Interestingly, there is an implementation of Python on the Java Virtual Machine (JVM) which both *runs* on the JVM and compiles Python programs to JVM bytecodes. JPython, as it is called, is a very complete implementation of Python--comparing favorably with the C implementation. By coupling the JVM with the datastore not only would we get Python, but we'd get Java as well. Two for the price of one.

   Even better, there has been a great deal of effort to produce compilers to the JVM for one's favorite language. Some of these, like JPython, themselves run on the JVM. Of particular interest to The Casbah Project is Kawa, a Scheme implementation running on and compiling to the JVM.

   Kawa is interesting for a number of reasons: The Casbah Project has some Scheme users in its crew, Kawa supports a good chunk of DSSSL, and, perhaps most importantly, the implementation is and has been worked toward being a language implementation framework. Per Bothner, the author, has already begun a ECMAscript implementation on the framework, and has tentative plans to build an ELisp compiler as well.

   Given that there are languages that The Casbah Project is interested in which are not yet supported on the JVM (or whose current JVM or JVM targeted implementation is not up to snuff), having a compiler framework which simplifies the task of compiling to JVM bytecode and hosting compilers on top of the JVM is very attractive.

   Importantly, we shall be building on the work of others as well as contributing to their projects.

Given these considerations, The Casbah Project has adopted the following strategy:

1. The core application framework shall be written in JPython, Kawa Scheme, or Java.

2. Thus, support for those languages and their implementations is primary. In particular, seamless integration between these languages is the top priority. One should be able to manipulate Python, Java, and Scheme values, expressions, and objects in any permutation from any of the blessed languages with minimal pain.

3. New language implementations will be built on top of the Kawa framework, which, in coordination with the author, will be modified and extended as necessary. In particular, integration with other Kawa based languages will be a prime feature of the framework and, thus, a prime advantage of using the framework.

The project comprising the second two tasks is called Cardamom. The general strategy of Cardamom is to make Java bytecodes the lingua franca of The Casbah Project.