Hi Ramin
First and foremost, thanks for your input.
Ramin said:
1) The XSLT engines on the server and client may not be the same, so
you have to be very careful what flavor of XSLT you use. Yes, it
was supposed to be all compatible, but in practice, XALAN-J on Solaris and
MS-XML on the desktop did things differently. With XSLT 2.0, the gap will get
even worse, I imagine.
Didier replies:
You didn’t created XSLT stylesheet
that uses the common denominator between these two engines. For
example not using the key construct.
Ramin said:
2) There was too much performance variance on the client.
Unfortunately, the server doesn't necessarily know the memory/CPU configuration
of the client before sending up raw XML. It seems to me the decision
point for whether to do the processing on server vs. client isn't whether the
client *has* an XSLT engine, but whether the user experience is enhanced by
doing it up there in the desktop. We thought of putting up a sort of
'pre-tester plug-in' up in the client to sniff out performance metrics and
communicate it to the server (the way videogames 'pre-test' your graphics card
and build a capability profile the first time you run them). Haven't tried that
yet.
Didier replies:
So it seems that your XSLT style sheets
where quite CPU demanding. The test I made on my side lead me to think that if
the XML document to be processed is not too big and the stylesheet having an
output quite similar to other web pages, then it seems to work on most PCs. On
very slow PCs even sophisticated HTML pages takes some time to render. I
discovered that the Microsoft engine is quite running fast enough for most
machines (taking into account the XML document size and template matching
complexity).
Ramin said:
3) You get a *lot* of performance boost if you can cache the
stylesheet and graphics up in the client. We used a programmable browser cache
program we had developed and the performance was much better since you usually
only had to download the raw XML data and could retrieve the XSLT stylesheet
locally. But since not every client has the cache software, you still have to
develop your server code to handle other clients.
Didier replies:
Very good point. I myself discovered that if the server settings are OK, the
stylesheet is cached on the client side (by setting the cache parameter for the
template). Since the XML document was dynamically created form a database I
could cache the XML document but just having the stylesheet parameters properly
set improved the overall performance since the Microsoft browser keeps the
documents in the cache as specified by the HTTP headers. So my question is: why
your team didn’t used the cache parameters to
set the Microsoft browser to cache the stylesheet?
Ramin said:
4) A pragmatic matter: when you're under deadline to build a web-based
application, you barely have enough time to finish the server-side code, let
alone branch it. Effectively you are writing two applications in one. You can
do some clever designs to reduce this work, but it's
extra work that would otherwise delay a project, requiring some advanced
programming, and may or may not provide a performance boost.
Didier replies:
Ramin it seems that this is a problem we encountered during these “irrational
exuberance” times. People thought that programming for the web was a
different affair than for other kind of programming task. I often heard the
expression “web time” to signify, in fact, sloppy development
methods J
Overall, I think the approach has merit. But the server frameworks
have a long way to go before being able to handle this automatically. Until
then, you have to roll your own.
Didier replies:
So bottom line, you didn’t got too much help from what’s actually on the shelves.
Many thanks Ramin,
Cheers
Didier PH Martin
