Re: problem with validated site

John L. wrote:

I highly recommend learning PHP, even if you only learn the basics, as even a little bit of server-side scripting can go a long way.

You mentioned having the links all in once place for easy maintenance. This is easy in PHP. Simply create a file with nothing in it but the navigation (links.html), then, whereever you want the links to appear in your web pages, just include it with PHP:

<div id="navigation">
<?php include('links.php'); ?>
</div>


Server side scripts are great. They're useful and quite transparent to the end user.
But, server side scripts have drawbacks that must be weighted against their benefits when compared to alternative reliable authoring strategies. They're not obvious at first sight, but these drawbacks are real. They negatively impact the server and the end user.

Server side scripts for extremely dynamic content, likely to change every few seconds or depending on form requests (e.g. search features) are perfectly fine.

But for static pages for which server side scripting would be used for maintainance purposes, they've tradeoffs:
1) HTTP cache control. For example, conditional GET operations will always think that documents have been changed and reload them.
This has a simple effect with most user agents: Everytime you navigate to a page of the site, it's entirely reloaded (except for the back history, with good browsers).

With static content, a conditional GET is performed (with good user agents), which requires very small network resources, and returns a small header indicating that the resource hasn't been changed. This greatly reduces the client and server bandwidth used. If an adequate expiration header is set, this conditional GET request can even be saved, sometimes!

In addition, if you use a HTTP proxy, it can cache the request.
This is useful for the end user if he has a better ping and bandwidth with his HTTP proxy (e.g. ISP provided proxy) than with your server (this used to be very true in the 1990's, but becomes less important nowadays). These proxy will also reduce the number of requests to your site, especially if it's very popular.

The HTTP cache control mechanism is really subtle. A large part of RFC-2616 deals with it. Dynamic pages break that.

2) Typically, the server don't send a compressed stream for dynamic resources even if the user agent declares a Accept-Encoding header including gzip, compress or other compression algorithms.
Compression can reduce by 3 or 4 the file size! Both the server and client benefit from this!

3) HTTP 1.1 partial downloading is very unlikely to work with dynamic content. This does matter for big files only. Below 400 kilobytes, it's not very important.

4) The Content-Length attribute won't be specified, though it can help the user agent. e.g. User agents use it to display a progress bar and automatically, or with user help, they may choose to stop downloading the resource if it's too large or to use an alternative download manager.
Actually, the HEAD method looses of its usefulness if the Content-Length attribute disappears.

Other minor detail: The Content-MD5 won't be provided while it could be useful on unreliable connections.

Overall, I've always had a better browsing experience with static pages than with dynamic pages thanks to the reduced and removed loading delays

Fortunately, it's possible to get a good authoring system, and yet, benefit from static pages for pages that don't change every second.

There are several solutions.
The first one, is to write scripts (e.g. PHP programs) that generate files and store them in appropriate places, with appropriate configuration files, on the server.
Then, when things are modified, a master script would be launched. It would simply generate all the pages from the scripts.

The second one is similar, but doesn't use scripts. It uses the SGML authoring capabilities.
It's less powerful, but is sufficient is all you need is SSI and a good management and versioning of individual files.

To do so, a tool is needed: An SGML normalizer. Ideally, it should be configurable to normalize only what's required. For example, it should expand entity references and marked sections (because they're not supported by existing HTML user agents), but shouldn't close omitted tags.
The spam utility of SP is a good choice:
http://www.jclark.com/sp/

The HTML files would contain an document type definition defined by an external and/or internal declaration subset.
Entities would be defined in external files shared by all the HTML documents, or in the internal declaration subset. With OASIS catalogs, the file management should be easy.
After having modified one or more file, you would just have to launch a script applying the normalization to all the HTML files, and storing the resulting files in the server directory.
That's a very simple batch job.

To benefit from this good authoring tool, you've to learn the basics of SGML. As a HTML author, knowing SGML is a good thing.
The following site is a good introductory to SGML:
http://www.is-thought.co.uk/book/home.htm

Maybe I'll start a debate around server side scripting... I'm sure we could learn more about the benefits and tradeoffs of server side scripting with the insights of experts.
--
If you've a question that doesn't belong to Usenet, contact me at <tabkanDELETETHISnaz@xxxxxxxxxxxxxxxxxx>
.

Relevant Pages