General Xcruciate project FAQ

The names beginning with X can all be blamed on Mark Howe. It is semi-traditional for XML applications to contain the letter X, and all the sensible options were already taken. Xcruciate sounded a bit like something formerly linked to a cross, which fitted with the project history. Xacerbate reflected how some people felt about the chances of the project affecting our coding problems, while Xiguous is supposed to be a concise way to describe virtual world functionality. And Xtravagate seemed excessively generic.

Barry Wickett decided to name his code after breeds of chicken, hence Maran. And Maran Cuckoo is a variety of that breed.

It all started in 2004 with Church of Fools, the world's first 3D online church, which was based on a Macromedia Flash server and a Director client. Mark Howe and Barry Wickett were both involved in the project from the start, though not in the coding.

After the project's widely-reported security problems, Barry and Mark decided to look at alternative ways to build virtual worlds. This led to the multimedia chat environment of St Pixels, with client and server written in java and perl respectively.

That environment works well, but Mark felt that it was too inflexible, and that the semantics were hidden in too many bits of procedural code. What he really wanted was a LISP machine. Then he realised that XSLT was (accidentally) a full-blown functional programming language. In addition, XSLT is an XML vocabulary designed to process XML documents, which, potentially, opens up the possibility of program-writing programs à la LISP. It's a widely-used W3C standard, and Daniel Veillard's LibXSLT in particular offers impressive throughput. Could XSLT be used as the basis of a real-time XSLT server?

The next stage was a proof of concept, which Mark assembled in perl. It worked well enough to establish the validity of the basic approach, but it soon became clear that in order to run efficiently it would be necessary to control LibXSLT at a finer level than perl CPAN modules allowed. Then we started to get stack dumps.

By this point Tony Graham was acting as a consultant on the project, and we decided together that implementing the XSLT virtual machine sooner rather than later made more sense than trying to fix what was probably an elusive bug in XML::LibXML that only appears when the same transformations are run hundreds of time on the same files (hardly a common perl scenario). So Tony recreated Mark's virtual machine in C, and then started to optimise it, resulting in Xacerbate.

Meanwhile, Mark started experimenting with approaches to programming the virtual machine under the project name Xiguous. We soon thought of cases in which an HTTP gateway would be useful, and Mark's third attempt turned into Xteriorize. Xtravagate was written to provide a convenient way to test the server functionality (the first generic client was in perl, but Perl/Tk struggles with UTF-8, which isn't ideal for an XML test bed). Finally, after taking one look at the interface for Xtravagate, Barry agreed to produce some java client technology.

We wanted to maximise opportunities for involvement and minimise the need for anyone to fork.

The concept embodied by Xacerbate is quite novel. It is also remarkably useless without some application code. But what should the application code look like? The Xiguous libraries have already been redesigned from scratch once, and we haven't finished learning about how to fit the quirks of XSLT around the quirks of our architecture. We wanted to produce a complete solution (the whole Xcruciate family), but we wanted to encourage experimentation at any level. So, for example, it is possible to use Xacerbate and Xteriorize to build web-oriented technology quite different to Xcathedra. It is possible to write another HTML gateway to use in preference to Xteriorize (or maybe to glue Xacerbate onto an existing web server). It is possible to start with just Xacerbate plus a bit of startup code in a scripting language and build a fundamentally different kind of XML API...

On a practical level, separate repositories means that XSLT gurus who are allergic to C don't need to wade through the C patches to Xacerbate and vice versa.

It's simple, it's widely-used, it's compatible with most other open-source code licensing and it doesn't preclude inclusion in commercial products.