Re: client side includes (fwd)

On Sat, 3 Feb 2001 14:28:55 -0800 (PST), "Russell O'Connor"
<roconnor@math.berkeley.edu> wrote:

>With client-side includes the particular piece of data only needs to be
>retrieved once.  This reduceds bandwidth.

Any data that is required, to serve a full document instance, from an
arbitrary server to an arbitrary client, must be "downloaded" at least
once through the full chain of caching mechanisms available on internet.

To "save" on the "next download" we need a "protocol" to help indicate
validity of data from the point of its origin and further through that
chain, so that individual parts of the "chain" can decide with some high
level of certainty that it is really only sending correct data further
downstream.

>HTTP/1.1 allows many entities to be downloaded with a single
>connection by using keep-alive. Thus there is no extra cost
>in making additional connections, only 1 is needed.

Exactly, RFC2616 has the details...

>Server load is further reduced by having the client ``assemble'' the
>document.

Not exactly a description of what is involved here, sorry to say.

The load on "internet" could be reduced to some extent, that's true.
[note that a correctly served data entity does not have to come from
 the originating server at all times]

>Given all these considerations, I don't understand why anyone
>would want to use server-side includes if a client-side include
>option were available.

I'm all with you on that, the entity inclusion mechanism has been around
for years and it's just (well let me not repeat my self:) that makes it
impossible to use on the www. Still, if we are "on the net" we would
need to get the entity declaration downloaded at least once, right? :)

-- 
Jan Roland Eriksson <jrexon@newsguy.com> <http://member.newsguy.com/~jrexon/>
Moronization: a form of acculturation where people are encouraged to anoint
themselves with the supposed benefits of a technology, without understanding
the engineering (or lack thereof.)

Received on Saturday, 3 February 2001 19:10:11 UTC