RE: client side includes

Frank Tobin [mailto:ftobin@uiuc.edu] wrote:

   I think you overstate your case.  Hitting the server for another chunk of
   data is not that expensive.  It happens all the time for images, CSS
   files, etc.

MM writes:

That's right! and that's the problem.  Did you ever wonder why Amazon changed to use one image with a map for their menu?  Ever wonder why Google use so few images?  Why so many commercial sites are reverting to using text for their menus?  Most responsive websites have optimized their design to make sure that image hits are reduced, ideally below the default of 5 connections that most UAs torture their users with.  

The web would be many times faster if a server could attach image files to the end of the html file and return one file.  No caching advantage you say?  There is no reason a smarter UA could tell the server which images it has already in the request header.  

It really is too bad we don't have a smarter http request header...  How many of you would like to know if a browser accepts JavaScript?  How many of you would like to know a browser's connection speed?  When I asked the author of http this question at a conference he replied "that doesn't belong in the request".  When asked why he said "its too big and would slow the entire net".  The truth is that most requests include a tons of junk like:

application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, etc....

How much would "language/javascript1.2" or "connection/dialup" really load the net?  Much less than <noframes>!




Frank Tobin [mailto:ftobin@uiuc.edu] wrote:
   Reduces server load how?  It certainly doesn't lower CPU load.  Perhaps
   you mean connection load; I've already stated my objection to this.

MM writes:
   FYI there is server overhead (and memory requirements) for accepting connections.



Frank Tobin [mailto:ftobin@uiuc.edu] wrote:
   Sure, most of us are aware of ssi's and the like.  But these solutions
   aren't portable, and aren't part of the markup language itself.  The best
   solutions are the ones you can carry from any server to another.

MM writes:
   That's why I like PHP and perl.  They are cross platform, free, and available for most any server.  It is easier to upgrade servers (happens all the time for security and feature fixes) than to get a low-income family to replace their web tv.



Frank Tobin [mailto:ftobin@uiuc.edu] wrote:
   We do know that server-based solutions are, in general, evil.

MM writes:
   The above comment is totally unsubstantiated and subjective negating your entire arguement.


Frank Tobin [mailto:ftobin@uiuc.edu] wrote:
   If the markup language itself handles the situation, that is the best solution.

MM writes:
   Best for who?  The low income family with the web tv?


Frank Tobin [mailto:ftobin@uiuc.edu] wrote:
   Personally, I've learned that entities seem like a good way do external
   includes.  So your entire argument is negated, since this functionality
   already exists in XML.

MM writes:

   A feature in XML has any bering on the wizdom of client side html includes?  Sorry Frank, I'm not following your logic here.

Dear people, don't bother flaming me with your wizdom, you're just being emotional.  Not one meaningful arguement that has been put forth for client side includes seems to have any reason other than to accomodate lazy developers or lame server configurations at the expense of all the existing UAs and the users that paid for them.  I believe that the responsibility for this situation falls on the developers, and making ALL existing html UAs incompatable to accomodate people not configuring their servers properly is NOT acceptable.  Not ONE low income family with a lame UA is being represented here.  

In closing, Includes are NOT a UA problem.  They are a server problem.  If servers need better compatability for SSIs then lobby MS and Apache, not the W3.

--MM.

ps: There are a number of free cross platform include solutions.  Just configure your server.  Its easier and more realistic than the entire public installing (or buying) new UAs.

Received on Saturday, 3 February 2001 17:05:45 UTC