Hi, I’ve recently been thinking about simplifying my future web
applications by making the back ends only speak XML … and using XSL
to present the information in browsers.
Although the browser world appears to be ready now for client-side
XSLT, I’m not sure the search-engines are… as a result I think I
must still perform server side XSLT.
I’m considering building an nginx module that could perform the
transformations, but not having any experience writing modules for
nginx, I thought I’d ask if this is wise? or maybe something like this
would be better suited being proxied to a separate HTTP service?
any thoughts would be appreciated?
–
Chris Farmiloe
What about using PHP or an application level script for it?
Otherwise, it could be done in the server (ZXTM touts this as a major
bonus) but it seems to me more geared towards the application layer.
It is a form of presentation, and the server shouldn’t really care
about presentation. Would you write the same module to translate JSON
to a destination output format? or CSV?
You will probably gain performance but I wouldn’t consider it suitable
for mainline inclusion into a server. It’s too specific and the
application layer typically does this kind of transformation work…
as an external module I’m sure some people would find it helpful
depending on their needs though.
The main benifit I’m after is being able to decide from the nginx.conf
something like this (pseudo):
if($user_agent is unable_to_perform_xslt){
xslt on;
}
This would allow me to offload the majority of the XSLT processing
client-side, but still support some of the older browsers, text-only,
screen readers etc.
I’m also a fan of a complete separation from application level code…
although XSL is about presentation, XSLT is simply the process of
conversion and unlikely to need modifying.
I see you’re point about converting between random formats, but if you
think about it… YES… if there was an XSLT module you could handle
almost any output you could create with XSL. and maybe even override
the style-sheet to use ie…
location ~* .csv$ {
xslt on;
xslt_stylesheet /xsl/csv.xsl;
}
It could allow you to create application servers that only talk one
language (XML) while allowing you to still build REST style services
that respond to multiple content types.
chrisfarms.
I already output all my data as xml and use xsl for templating, however
at the moment I’m using php to handle the translation. A native nginx
module would be a great idea!
Chris Farmiloe wrote:
nginx, I thought I’d ask if this is wise? or maybe something like this
would be better suited being proxied to a separate HTTP service?
any thoughts would be appreciated?
–
Phillip B Oldham
The Activity People
[email protected] mailto:[email protected]
Policies
This e-mail and its attachments are intended for the above named
recipient(s) only and may be confidential. If they have come to you in
error, please reply to this e-mail and highlight the error. No action
should be taken regarding content, nor must you copy or show them to
anyone.
This e-mail has been created in the knowledge that Internet e-mail is
not a 100% secure communications medium, and we have taken steps to
ensure that this e-mail and attachments are free from any virus. We must
advise that in keeping with good computing practice the recipient should
ensure they are completely virus free, and that you understand and
observe the lack of security when e-mailing us.
Again - I see this as being still making sense to reside in the
application layer, since the possibilities of inputs and outputs are
infinite (well, could be…)
I’m not sure the browser reliably reports it’s XSL processing
capabilities without using JavaScript, in which case, you’ve probably
already side-stepped the webserver (or, you have to use all this in
combination with each other)
I don’t believe there is still any consistent client-side XSL that can
be adopted that is safely cross browser and such. Last I checked
Google had an XSL processing library that was as close to
cross-browser as it got, but it still wasn’t 100%.
I’m not saying it’s not worthwhile for some folks. I am just not sure
it’s meant to be in an nginx supplied module. Extensions obviously
anyone can cook up for any reason… and XML/XSL offloading is a
common desire (ZXTM does it, there’s some hardware appliances even
that will do it for you) - someone has already said they’d love it for
their application - the need -is- there, but I’d rather it be
something external to core nginx development as there are some other
features that should reside in the server that have not been finished
yet…
What would be useful is if you could define the root where the processor
looks for the stylesheet, and have this seperate from the webroot. For
instance, if my xsl file was located at:
/var/www/mydocs/xsl/products/default.xsl
And in nginx:
location / {
root /var/www/mydocs/app/;
xslt on;
xslt_root /var/www/mydocs/xsl/;
}
And the output XML:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/products/default.xsl"?>
As for whether this should be a bundled or third-party module, I’m with
mike’s comments - while its useful to some people, I wouldn’t consider
it “core” and would be happy to grab it from an external resource.
Chris Farmiloe wrote:
xslt on;
–
Phillip B Oldham
The Activity People
[email protected] mailto:[email protected]
Policies
This e-mail and its attachments are intended for the above named
recipient(s) only and may be confidential. If they have come to you in
error, please reply to this e-mail and highlight the error. No action
should be taken regarding content, nor must you copy or show them to
anyone.
This e-mail has been created in the knowledge that Internet e-mail is
not a 100% secure communications medium, and we have taken steps to
ensure that this e-mail and attachments are free from any virus. We must
advise that in keeping with good computing practice the recipient should
ensure they are completely virus free, and that you understand and
observe the lack of security when e-mailing us.
I second that. XSLT really belongs to the application level. For
instance, you
might want to allow users to select different stylesheets for the same
page
(e.g., different skins). If you offload the XSLT outside your
application,
you lose this ability.
Besides, I don’t think nginx would be able to do it considerably faster,
it’d
probably use the very same libxslt.
Hello!
On Tue, Apr 08, 2008 at 06:32:57AM -0400, Denis S. Filimonov wrote:
I second that. XSLT really belongs to the application level. For instance, you
might want to allow users to select different stylesheets for the same page
(e.g., different skins). If you offload the XSLT outside your application,
you lose this ability.
Not really, since you can control what happens via external means
(X-Accel-XSLT?) or even internal XSLT means (see thread for
xslt_root proposal - but personally I think it would complicate
[efficient] implementation too much).
Besides, I don’t think nginx would be able to do it considerably faster, it’d
probably use the very same libxslt.
The main thing nginx can do to speed up things is XSLT parsing /
caching. This may be sometimes tricky at backend level.
But this is definetely not the argument for XSLT itself. If you
need speed - you don’t use XML. 
My main motivation for nginx xslt module is to do things
simple, manageble and interoperable.
Maxim D.
Hello Maxim,
Tuesday, April 8, 2008, 5:37:34 PM, you wrote:
Hello!
On Tue, Apr 08, 2008 at 10:02:47AM +0100, Chris Farmiloe wrote:
nginx, I thought I’d ask if this is wise? or maybe something like this
would be better suited being proxied to a separate HTTP service?
any thoughts would be appreciated?
I’m planning to implement nginx XSLT module for a while, and
studied the problem in detail.
The main problem with XSLT is that in general you can’t transform
XML document unless it’s fully parsed, and thus nginx will be
forced to buffer entire backend answer before transforming. This
will have obvious memory implications.
So, if you already have your XML parsed somewhere in you app - it
would be more efficient to transform it there.
+1, see mod-xslt2 for apache.
Maxim D. ha scritto:
[…]
I’m planning to implement nginx XSLT module for a while, and studied the
problem in detail.
The main problem with XSLT is that in general you can’t transform XML
document unless it’s fully parsed, and thus nginx will be forced to
buffer entire backend answer before transforming. This will have
obvious memory implications.
No problem with Nginx, it can buffer on a temp file (and you can force
it to always buffer to a temp file), so you can just run the XSLT
processor as a separate process and send the resulting file to the
client (perhaps using sendfile).
Unfortunately Nginx does not offer an infrastructure for process
handling to be used by modules.
So, if you already have your XML parsed somewhere in you app - it would
be more efficient to transform it there.
Maxim D.
Manlio P.
Hello!
On Tue, Apr 08, 2008 at 10:02:47AM +0100, Chris Farmiloe wrote:
nginx, I thought I’d ask if this is wise? or maybe something like this
would be better suited being proxied to a separate HTTP service?
any thoughts would be appreciated?
I’m planning to implement nginx XSLT module for a while, and
studied the problem in detail.
The main problem with XSLT is that in general you can’t transform
XML document unless it’s fully parsed, and thus nginx will be
forced to buffer entire backend answer before transforming. This
will have obvious memory implications.
So, if you already have your XML parsed somewhere in you app - it
would be more efficient to transform it there.
Maxim D.
Thanks for all your comments. In summary:
pros:
– some nice tricks could be done to switch transformation templates
based on the request (or even not transform at all in the cases where
clients can do it themselves)
– probably some good opportunities for caching of xsl templates
cons:
– very likely to be less efficient at nginx level since we would
have loaded the XML tree into memory twice (once in app server and
again in nginx to perform transformation)
Because of my particular need to only process transformations for
legacy clients, I think a third-party xslt module is still an option.
But I hadn’t thought about the rather pointless double XML parsing, so
I’ll have to think a bit more.
chrisfarms
Hello!
On Tue, Apr 08, 2008 at 01:31:34PM +0200, Manlio P. wrote:
No problem with Nginx, it can buffer on a temp file (and you can force it
to always buffer to a temp file), so you can just run the XSLT processor
as a separate process and send the resulting file to the client (perhaps
using sendfile).
This will have obvious disk, processor and memory implications,
and will throw away any benefits from pre-parsing of xslt files.
Any xslt processor needs xml tree in memory to do transformation,
and moving the task to a separate process doesn’t make things
better.
Maxim D.
Am 08.04.2008 um 15:33 schrieb Phillip B Oldham:
I don’t think its a definate that the XML tree is going to be loaded
into memory twice. Some apps might build the XML as a string (ugly,
but possible), or simply pass-through an existing file. There’s even
the possibility that it might pass-through from a feed of some kind
if nginx is working as a load-balancer/reverse-proxy.
Given the right features I think such a module would be a great
addition to a great webserver.
Also have a look at deliverance, which is developed for the usecase to
skin different inputs.
http://www.openplans.org/projects/deliverance/project-home
Probably together with the wsgi-module from Manilo.
With regards,
__Janko
On Tue, Apr 08, 2008 at 10:02:47AM +0100, Chris Farmiloe wrote:
nginx, I thought I’d ask if this is wise? or maybe something like this
would be better suited being proxied to a separate HTTP service?
any thoughts would be appreciated?
I’m not a proponent of idea to run XSLT on server side: I prefer to
pregenerate HTML. However, it seems I will make XLST filter to process
small XML SSI inclusions.
I don’t think its a definate that the XML tree is going to be loaded
into memory twice. Some apps might build the XML as a string (ugly, but
possible), or simply pass-through an existing file. There’s even the
possibility that it might pass-through from a feed of some kind if nginx
is working as a load-balancer/reverse-proxy.
Given the right features I think such a module would be a great addition
to a great webserver.
Chris Farmiloe wrote:
have loaded the XML tree into memory twice (once in app server and
–
Phillip B Oldham
The Activity People
[email protected] mailto:[email protected]
Policies
This e-mail and its attachments are intended for the above named
recipient(s) only and may be confidential. If they have come to you in
error, please reply to this e-mail and highlight the error. No action
should be taken regarding content, nor must you copy or show them to
anyone.
This e-mail has been created in the knowledge that Internet e-mail is
not a 100% secure communications medium, and we have taken steps to
ensure that this e-mail and attachments are free from any virus. We must
advise that in keeping with good computing practice the recipient should
ensure they are completely virus free, and that you understand and
observe the lack of security when e-mailing us.
Greetings Chris!
It is definitely good idea to use STX instead of XSL due to
nginx’s FSM architecture. This will allow also to scale
significantly more, since no complete XML tree will be stored
in memory.
Chris Farmiloe пишет: