Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Client-side XSLT. Re: Bad News on IE6 XML Support
 > 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
