Database->python->Xml->Xslt->Client

[john]

Hi
I am devlopeing a data centric intranetsite with data in mysql
database
I would like your opinion on this architecture
Data will be fetched from database by python & converted into xml
The XSLT will be stored on the client cache.So only the xml is
transferred to client & the xslt transforms it into xhtml & displays
it.
Will this improve performance or have i gone nuts??

 

[=?iso-8859-1?Q?Michel_Claveau_-_abstraction_m=E9ta]

Hi !

It is an architecture "en vogue" ; but AMHA, XML is verbose.

@-salutations

 

[Alex Martelli]

Michel Claveau - abstraction méta-galactique non triviale en fuite

It is an architecture "en vogue" ; but AMHA, XML is verbose.

Not any more verbose, typically, than HTML doing the presentation of
whatever data the XML is encoding, which I take is the alternative John
(the OP) is comparing again (he didn't actually explain the alternative
architectures he's considering, but that one would appear to be the
default...). If the XML is a high semantic level it can end up quite a
bit more compact than the HTML needed for nice presentation, even when
you factor out a lot of CSS from the latter to rely on the CSS getting
cached.

Fashion apart, I do think the proposed architecture may improve
performance compared to having the server prepare and send all HTML. It
spreads the computational load (if the XML the server is sending is
pretty close to the database's content, at least) and may even reduce
the bandwidth (often not a key bottleneck in an intranet, particularly
these days with gigabit ethernet finally becoming cheap... but sometimes
VPNs and the like do extend an intranet over links where bandwidth CAN
be a problem!-).

Having the server supply raw data and spreading out even more work to
the clients would be more of the same, but would require way fatter
clients, and that carries its own set of issues. What the OP described
can be done easily by decent browsers, today, with no need for fat
clients and all of their many issues.


Alex

 

[=?iso-8859-1?Q?Michel_Claveau_-_abstraction_m=E9ta]

Hi !

HTML also is verbose...

 

[Izzie]

Will this improve performance or have i gone nuts??

Since you have more computationally intensive steps
(XSLT is no walk in the park) to do I don't think that
it will directly improve the performance at all.

What gets improved is the modularity and generality
of your solution. In your system you can now freely
interchange the backends and frontends. You program
will work with any other backend that produces XML
and any other display that can transform from XML.
This independence can be great.

On the other hand I have been seriously bitten
by XSLT. Writing complicated and reusable stylesheets
that remain readable seems to be impossible.
And it is difficult to foresee how complicated
the stylesheets need to be.

The weakest link in your pipeline is XSLT.

Istvan.

 

[Paul Boddie]

Hi !

HTML also is verbose...

Thanks for that informed commentary on the matter. I'm sure the
verbosity of HTML and XML with respect to your favourite binary wire
format (and presumably your favourite client software, too, given that
we're looking at a browser solution) really passed the original
contributor by.

Back to the suggested architecture: if you're purely worried about
network bandwidth, then provided the XML is much smaller than any
presented page, I suppose you could use client-side XSL in order to
reduce the bandwidth requirement. But if any reduced bandwidth
requirement is just one way of getting better performance, I'm not
completely convinced that you wouldn't be better served with something
like libxslt on the server producing the final output; in my
experience, its performance is pretty impressive on modest hardware in
comparison to other such processors (on much bigger hardware).
Moreover, by retaining XSL processing on the server, you would avoid
potentially controversial browser requirements - it's bad enough
working round browser issues with supposedly "simple" stuff like XHTML
and CSS without bringing XSL into the equation.

Paul