Alexei Kosut (
Fri, 5 May 1995 21:19:44 -0700 (PDT)

Date: Fri, 5 May 1995 21:19:44 -0700 (PDT)
From: Alexei Kosut <>
To: Multiple recipients of list <>
Subject: Re: INCLUDE tag
In-Reply-To: <>
Message-Id: <>

On Fri, 5 May 1995, Steve Abatangle wrote:

> 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 

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 

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 

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:


* 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.


* 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
  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 <>