W3C home > Mailing lists > Public > www-html@w3.org > August 1998

Re: SSI usefulness (was RE: OBJECT, inheritance, and rendering)

From: Mike Meyer <mwm@contessa.phone.net>
Date: Fri, 7 Aug 1998 09:26:38 PST
To: www-html@w3.org
Message-ID: <19980807.760D9C0.8C50@contessa.phone.net>
> At 4:22p -0700 08/05/98, Mike Meyer wrote:
> >> Umm, could someone explain the advantage of a CSI over a SSI?
> >
> >CSI takes advantage of caches. SSI pretty much defeats them, though
> >some implementations manage to do a bit better, and datestamp the
> >document with the date of the latest part used to build it.
> 
> I don't really understand caches and proxies, but isn't it *their*
> responsibility to work with what a server generates? Or is the problem
> that some header is missing?

Well, missing creation date headers is a problem in some SSI
implementations. Ditto for handling if-modified-since requests. Those
can be fixed *at the server*.  However, the various caches only see
the *assembled* page, not the components. So if you have some
component that shows up on many pages, you have to send a copy of that
data for every page with SSI. If it's done with CSI, then, like
images, the first page to use it causes your browser to fetch it, and
the rest can use the cached copy.

> >CSI also
> >lets you build documents from pieces on different servers - allowing
> >you to imbed a search result from the HTTP interface to an SQL server
> >in a document that comes from a off-the-shelf HTTP server.
> 
> Heh, I'd like to see how you'd ensure the integrity of that document's
> HTML structure. ;)  Sounds to me like a recipe for browser-crashing.

This is the standard argument *against* an include facility.

> >> I cannot think of a single application for a client-side include.
> >
> >There aren't very many *usefull* things to do with SSI. Eliminate
> >things that are better done with a server-side build model and there's
> >very little left.
> 
> CNET does everything with SSIs, and probably wouldn't be able to do what
> they do otherwise. We also use it at SLAC so that anyone here can include
> the list of current announcements on their pages. I will also be using it
> on my own site to generate a pseudo-random quote (see my test page at
> <http://www.natural-innovations.com/testcgi.html> -- reload it a few times).

I'm not familiar with CNET's stuff. The list of current announcements
is a good candidate for a server-side build (*not* the same thing), if
it's fairly static. See below for a second comment.

> >See <URL: http://www.phone.net/home/mwm/no-ssi.html> for more information.
> 
> I read it, and I disagree. Or are you just saying that a page which would
> otherwise contain an SSI should instead be replaced with a Perl script
> that assembles the page and then passes it on to the server? I hope you're
> not saying that pages should never be generated on the fly...

No, that's not what I'm saying. After you eliminate the fluff (like
random quotes) and bad ideas (like pages that change the HTML based on
the client), you're left with either real dynamic data - for which SSI
generally isn't sufficient - or things that tend to be built from
parts, and then served to many people with the same content. Given
that disk is cheap, upgrading disk is cheaper than upgrading CPU, and
the cache problems mentioned above, the latter is *much* better done
by building the page once and updating it when one or more parts of
the data change.

	<mike
Received on Friday, 7 August 1998 12:32:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:37 GMT