Symphony.

No, we don't have any news on this front at this point in time, I'm afraid. This is however on all of our minds so we will be looking at this again once our existing slate of work is complete and ready take this on again.

Apologies for the delayed response -

Our focus was on getting a stable Saxon/Symphony setup working. This was successful, however the stack performance was not really usable for anything other than the smallest of sites. As a result we dropped this effort, focusing instead on creating a reusable image for high performance delivery.

Update @14:45: Heh - I had this page loaded from a few days ago and hadn't see Allen's comment

Guys, and what about fast'n'furious NGINX? :-)) AFAIK, it has several modules for XSLT2 transforms. proof link: http://xxslt.sourceforge.net/?id=xslt2

Nginx is cool, not used it myself yet, but heard good things on here though.

I think the goal is to support the greater requirement, which unfortunately has no native support for XSLT 2.

If a user can control the environments that they host the sites on, and want to support XSLT 2, then they have the choice, but most like myself don't and have to stick with libxsl.

Lots of the functionality that XSLT 2 adds, can be achieved in XSLT 1, using EXSL and other functions, it's just a longer way round and a harder learning curve.

nginx is very fast when it comes to:

• serving static files
• load balancing

If we talk about Symphony websites (where PHP has to do the heavy lifting), you will have a hard time to get an nginx setup significantly faster. I tested this myself. Without going into too much detail here, in the end I decided to use Apache/mod_php for stability reasons. This combination is rock solid.

Guys, what i meant was to eliminate the words "Symphony websites where PHP has to do the heavy lifting". Suppose the web server could achieve these tasks in much quicker and elegant way with xslt/xslt2 modules. Or am i wrong? ;-)

XSLT is typically the least resource intensive aspect of the system stack. Its role in a system is the transformation of content to presentation. This only makes up one part of many in a fully functioning system, which must also account for authentication, URL rewriting, database management and many other aspects that a system needs to manage.

The shift to XSLT 2.0 may see some performance improvements, although it'd be negligible in the grand scheme of things. I'd argue that the added complexity that XPath 2.0 brings and the increase in functionality scope for XSLT 2.0 won't necessarily make the transformation processing generally faster. The improvement moving to 2.0 would be predominantly for coding convenience.

" = on the money