[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Client-side XSLT. Re: Bad News on IE6 XML Support
- From: Paul Tchistopolskii <email@example.com>
- To: Jeni Tennison <firstname.lastname@example.org>, 'xml-dev' <email@example.com>
- Date: Sun, 09 Sep 2001 15:29:32 -0700
> The argument that I've heard for client-side transformations is that
> they ease the load on the server. Presumably this is particularly true
> with dynamic applications where the results of the transformations
> cannot be cached. It would also be faster for the client if the same
> stylesheet/XML were used as the basis of multiple pages - they would
> only have to download the XML/stylesheet once, rather than accessing
> multiple HTML pages.
Serverside can also precompile the stylesheet ( but it better to cache
the *result* of transfromation, because it saves 95% but not just
5% saved by stylesheet precompiclation) .
Look at AxKit / Hiawatha. If it could be cached server-side - outsourcing XSLT
stylesheet to client side buys *nothing*. If it can *not* be cached serverside,
that means something like some SQL queries has to be executed e t.c. -
placing XSLT Stylesheet on client side would not save you, because
SQL queries have to be executed *server-side* and placing XSLT stylesheet
client-side will save a fraction of load. Not more than 5%.
So all this buzz is about saving 5% of server load? I thought that the first
thing that CS student learns is that optimizations have to be
applied to the *bottlenecks*, because using some 'abstract' optimization
not even profiling the application is a lame unprofessional behaviour.
So what is the bottleneck of XSLT transfrormations? What *in particular*
get's optimized with client-side XSLT ?
Could somebody please show me a *single*benchmark* illustrating
that client-side XSLT load-balancing works and saves 'that much'.
I feel *very* incomfortable, telling such an obvious things that are better
to be told to first year students, but not to professional developers
( well ... maybe there is no professional developers on XML-dev list -
in this case I apologize ). It could be that I don't understand something
obvious - in this case I also apologize.
Wirh Java RMI is was possible to get a *real* load-balancing between
browser and server, but Java RMI has been killed by MS, so this
'XSLT-based' load balancing *is* a pipe dream which has *no* proof
in the real life. Show me *any* *actual* system which is based on
client-side XSLT 'load balancing' and with a big probability I'd show
how to turn it into server-side XSLT with some caching *and*
I think that my solution will give *more* freedom to the server.
> Server-side engines such as Cocoon and XSQL simplify auto-detection,
How many websites do you know, which are powered by Cocoon?
Honest? I know not more, than 10. Sure. Cocoon. The product,
promoted by Apache group. Unfortunately, the Apache group itself
is *not* using this cool product for their own website.
> so that you get client-side transformation when it's available and
> server-side transformation when it's not. However, this is still done
> through browser name/version rather than through a more general
> mechanism such as the HTTP Accept request field, as far as I can tell.
Could you please give me the URL ? It is all very much hypotetical
without the actual URLs that will *do* that selection.
> To my mind, even when/if we have several browsers what implement XSLT,
> we will still have a problem with client-side stylesheets because of
> the question of how you pass parameters into the stylesheets. To do
> order to create and populate DOMs. I haven't had a chance to
> experiment yet with what you can do within Netscape/Mozilla.
It is worse that that. Parameters are not the only problem.
In principle - if the transformation is not dynamic - just use AxKit / Hiawatha
approach and cache the result serverside. No need in any client-side XSLT
rendering at all. If transformation *is* dynamic - the only way to fight against
that is some not-obvious caching senarios and Browser gives you *zero*
API's for that. This means that smart caching could be implemented
*only* serverside. For example, there is no way HiawathaZ incremental
rendering can me implemented client-side.
That's why I constantly ask for particular examples of client-side XSLT
in production, not about 'what could be done'. Building distributed
application with some funny interperter that was created for absolutely
another purpose ( XSLT ) ? Sounds a bit *strange*.