Xacerbate FAQ

This FAQ is for questions concerning Xacerbate, the Xcruciate XSLT engine.

Why didn't you use XSLT 2.0?

6 Jan 2009 at 01:00 by mark

We chose LibXSLT as our parser because it is fast, stable and extensible. At present there is no LibXSLT 2.0.

XSLT 2.0 would certainly offer significant benefits for the application-layer coding, such as native functions, an end to RTF/node-set() madness and fully-integrated document validation. But we don't currently feel like writing our own extensible XSLT 2.0 parser in C. If or when someone else does that we may well revist the XSLT 2.0 question.

0 comment(s) so far, not open for comments

Why didn't you write Xacerbate in java/perl/python/visual basic?

6 Jan 2009 at 01:00 by mark

The earliest prototype of Xacerbate was written in perl. There were two problems with this:

  1. The standard CPAN libraries didn't offer support for implementing features such as document cacheing, which seemed important to us to maximize efficiency
  2. We encountered some LibXML2/LibXSLT memory issues that seg-faulted perl, and trying to identify - let alone - fix those issues looked like a long and uncertain journey

Our best guess was that the memory issues were due to conflicts between the C XML libraries and perl regarding the meaning of 'freed memory'. The best way to avoid those issues was to take control of the memory management. In other words, the low-level nature of C was for once a feature! Also, Tony had experience of using the LibXSLT library to build C applications.

Xacerbate is not intended to grow into an ever more complex application. It needs to do a relatively simple job as efficiently as possible, to support the interesting stuff at XSLT application level. For that brief, C looked like a fairly good choice.

0 comment(s) so far, not open for comments

When can we expect support for secure sockets?

6 Jan 2009 at 01:00 by mark

Never say never, but it is not currently a priority. The sort of applications we had in mind when developing Xacerbate do not require military-grade security. Using secure sockets for all data uses significantly more resources for both client and server. Including third-party secure socket technology would require us to be very vigilant regarding security issues in that technology - the only thing worse than no secure sockets is insecure secure sockets. Particularly sensitive data such as passwords can be processed via SSL using Apache proxying to Xacerbate via Xteriorize.

0 comment(s) so far, not open for comments