Re: Netscape Support for XSL - client vs server rant

Subject: Re: Netscape Support for XSL - client vs server rant
From: Matt Sergeant <matt@xxxxxxxxxxxx>
Date: Fri, 19 May 2000 19:18:01 +0100 (BST)
On Sat, 20 May 2000, Dan Morrison wrote:

> Heather Lindsay wrote:
> > 
> >         If it's not too much trouble could you elaborate on this speed
> > penalty you speak of?  How much of a speed penalty is it?
> 
> 
> To butt in before Matt gets a chance...
> 
> The difference between sending off a network request to a server vs
> processing changes on the client is more than significant. It can make
> or break the effectiveness of the user experience.
> 
> Without wishing to downplay the power of Cocoon et al, the dynamics that
> are unleashed by sending the /data/ to an IE client, which can then be
> manipulated by client-side scripting, is astounding.

While being the implementor of one of these server side solutions, I agree
completely, however you're not seeing the whole picture...

> In so many ways this is a better model of information transfer and
> management. Send the data, send some instructions on how to display it
> /and/ send instructions on other things you can do with it. 
> Server-based solutions (servlets or not) always require the overhead of
> the network transfer, and mean that at any time you are looking at only
> a cooked interpretation of the information. It's not true EDI in my
> book, it's just database-driven HTML, and the fact there's some XML
> thrown in there behind the scenes has no perceivable advantage to the
> user.

Except for the fact that the user gets access to all the benefits of
stylesheets without having to have the latest and greatest browser.

> I'll go out on a limb here, and (to mix my metaphors) will probably be
> shot down in flames, but it could be said that the concentration we see
> on server-based solutions is not just making up for the dodgy support
> currently available in client browsers, but actually reactionary against
> the fact that the MS integrated model is actually a Good Thing [TM] and
> some folk are loathe to admit it.

It's not reactionary at all - but in fact a stepping stone. Certainly
AxKit is. Sadly Cocoon is broken by default in this respect, but that's
another matter. With AxKit I explicitly have given developers the chance
of writing a "Passthru" plugin, so that they can detect browsers which are
XSL aware and send pure XML. For people not so lucky the plugin doesn't
activite it's passthru flag and they get XML transformed on the server.

> Yes they got 5% of the implimentation wrong, but the concept is correct.
> This is why NS is playing catch-up with XML support. This is why I for
> one am looking forward to the day they get there.
> This is why in any of the online applications I design, I push as much
> data down to the client as possible and minimise server dependancies.
> 
> 
> As a developer I _like_ server-based solutions. I have control. I have
> to worry less about browser sh*t. I can pull clever tricks in the
> language of my choice. I can upgrade my platform whenver I need to to
> take advantage of new features.
> 
> As a thinking person however, giving the client control is "morally"
> better. And logistically correct. And, in sub-cable conditions, usually
> much quicker, when done right.

And here's the major point you're missing. You're thinking desktop,
browser based display. That's such a small box. Do you really think people
are going to be installing XSLT engines in WAP devices so that they can
fit into your ideal world? I don't. At least not for a few years. And even
then I want to be able to support the people who don't have the latest
and greatest. XSLT is massively resource consuming, and the benefits of
sending pure XML to a WAP device (or Braille, or other W3C supported media
device) are going to be much smaller than sending it to a browser on a
desktop machine.

> I imagine this will raise a few hackles, but I believe the attitude to
> the client-server relationship is an important aspect of XML, XSL, and
> the success of the movement as a whole.

It's not a one way street. That's what AxKit is about - flexibility.

-- 
<Matt/>

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread