- From: Mike Meyer <mwm@contessa.phone.net>
- Date: Fri, 7 Aug 1998 09:26:38 PST
- To: www-html@w3.org
> 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 UTC