Skip to main content

Just Thinking....

Think....

A web service (or maybe just a ASP page) renders and serves an XML generated based on the inputs passed to it.
A web browser picks it up, uses XSLT to transform it into a lovely page.

And what do you get, an application which does not waste too much time on the server.

Do not speak, just think.....Does nt your mind do a full revolution???

Anyway my friend really sparked that idea, said he has seen it implemented somewhere. But it was scrapped, cos of the sheer volume. (i dont wonder what he is talking about).
Just as an afterthought i do wonder how long will Gmail function. (wont it be complicated using XmlHTTPRequest all over your page).

Comments

Rakesh Pai said…
This is not a new idea, and I've seen this being done at a lot of places myself. But this idea is not without it's set of problems.

The biggest problem would be that old browsers do not know how to handle XML.

One way of handling this problem would be to have a server-side browser sniffer.

if browser=old
XSLT from xml to html
else
send xml

But, on second thoughts, is it so much of a waste of time on the server to generate markup? What about the effort the server will have to put in to generate the XML in the first place?

The real benefit of this would be if there are many types of clients consuming the XML and processing them (in any way). But if you are really only making web services that are used to generate web-pages, XML is hardly that useful.

But then again, you could talk about future-proofing...

Popular posts from this blog

So you have your website deployed in PROD ... now what ??

Posting on behalf of Usr.Web.Speed - My previous job had been to architect and develop websites for various customers. During that time my team and I have architected and developed various web applications mainly for enterprises. (But below info is not restricted to enterprises) Other than the usual development and testing tasks involved, our focus area was to abide by multiple SLAs. One of the primary SLAs was to provide the users of our websites a very low (usually subsecond) response time (or page load time). To adhere to this SLA, we did multiple activities, in code, process as well as infrastructure. These include (but not limit to) - Using best practices including (http://developer.yahoo.com/performance/rules.html) Determining the optimum number of calls to the databases, open connections, etc. Providing the fastest mechanisms to download associated content (such as stylesheets, JS files, etc. over CDN) And debugging the reason for the slowness of the websites, when ...