> This is why we need <INCLUDE> tags. It's time we thought about the future,
> as in 5-10 years from now -- not next week. The internet's bandwidth will
> grow, and the speed of computers will increase. We needn't worry about
> network traffic or display times.
Whoa... wait a minute. Of course we need to worry about network traffice
and display times. The Internet's bandwidth will grow, yes, but not fast
enough. And it gets more congested every day - I happen to know that
several Austrailian universities charge their account-holders for each
overseas packet they send, because of the limited bandwidth and large
cost.
As for display time, this is a very pertenent issue. The WWW is not just
a collection of documents that sits somewhere and collects dust - people
use it. And they don't like to wait. And even with increased net
bandwidth, those of us stuck behind 14.4k PPP links still suffer. I have
Auto-Load Images turned off in my browser because pictures take too darn
long to load - if I want one, I'll load it, and it's easy, but it takes
time.
And if we shouldn't be worried about connect time, then why are HTTP 1.1
and HTTP-NG being developed to fix this very problem? They both, to
varying degrees, will allow multiple requests in the same connection, the
only purpose of which can be to conserve net bandwidth and increase
thouroughput.
If you don't think either of these issues are important, than you
probably either someone with a nice, speedy, connection to the Internet, or
are just an optimist. Me, I'm neither.
Back to the issue at hand, that of includes, I agree that they are a neat
feature, and I see several pros and cons of client-side includes vs.
server-side includes:
Pros:
* It lets you include a document from anywhere, not just the local machine.
* It puts less strain on the server, the client is responsible for
handling the constituant parts.
* If that document is cached, i.e. a company heading or something, it can
be displayed quickly and easily.
Cons:
* It's bandwidth-wasting - if it's a local document, it's much easier for
the server to tack on the document intenally.
* It's time-wasting. Here, let me show an example. I have a document, we'll
refer to it as /doc.html. It has four pictures (/pict1.gif-/pict4.gif), and
an included file (/include.html), which itself has three pictures.
(/pict5.gif-/pict7.gif). This example assumes a client that can do
threaded requests, but still works with non-threaded browsers.
First, with client-side includes:
1) The client requests /doc.html. The server sends it to it.
2) The client reads the document, and finds references to four pictures
and an include. It requests /doc.html, /pict1.gif, /pict2.gif,
/pict3.gif, and /pict4.gif. The server sends them.
3) The client looks at its new include, and sees three more pictures.
It connects to the server again, and asks for /pict5.gif,
/pict6.gif and /pict7.gif.
Now, with server-side includes:
1) The client requests /doc.html. The server inserts the include.html
file.
2) The client looks at the file it got, and sees seven images. It goes
and gets them.
The client-side includes takes nine connections, and is done in three
passes. The server-side includes take eight connections, and is done
in two passes. More network-economical, and faster.
* Puts less demand on the client. The server can worry about inserting
the document, the client doesn't have to keep track.
* Backwards-compatibility. With a client-parsed include tag, many old
browsers would be unable to include the file, not understanding it.
Well, that's all I can think of right now. I don't know which is better,
but I'd assume server-side... to put this another way: Note that NCSA, I
believe the first to use includes, put them in their httpd, not into
Mosaic, both of which it delevoped.
Or to put this another way, if you're reading a book, and you come across
a footnote number, you don't have to go back to the bookstore and buy a
little slip of paper with that footnote on it. No, the publisher has
included it on the bottom of the page.
Just some things to think about. I dunno. I'm probably wrong.
-- Alexei Kosut <akosut@nueva.pvt.k12.ca.us> URL: http://www.nueva.pvt.k12.ca.us/~akosut/