Re: Client-side XSLT. Re: Bad News on IE6 XML Support

[Paul Tchistopolskii <pault12@pacbell.net>]

> 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
> this with IE, you have to write some Microsoft-specific Javascript in
> 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*.

Rgds.Paul.