RE: client side includes

Murray Macdonald, at 14:07 -0800 on Sat, 3 Feb 2001, wrote:

    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 changes could be either for bandwidth or latency issues.  Images
contribute to bandwidth and latency; client-side document includes
generally more contribute to lantency, not bandwidth, more than anything.

    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.

Minimal, at most.  Certainly not as much overhead as the server creating
the documents.`


    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.

web-tv's are about the only browser not upgradeable.  They are the
exception to a propagation of free (in both senses of the word) and
upgradeable browsing systems (and probably wont' be for long).

    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.

The whole point of XML entities is to enable parser-side includes!
Macroization is a good thing!  I'd figure that if the W3 people put
external entities into XML there was a good deal of thought about doing
this; hence, there is likely wisdom behind this decision.

    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.

First, _I'm_ being emotional?  Perhaps you should read the message I was
replying to, which was chock-full of anger.

A good meaningful argument is that if the document is understood as
consisting of discrete parts on the client-end, the client can do caching
easily, just as it is done with images.  The caching would come with
virtually no changes to negotiational HTTP protocol, and external entities
appear fairly trivial for an XML parser to be capable of handling.

Lazy developers are good things.  Read about the Tree Great Virtues of a
Programmer (http://www.helsinki.fi/~arimakel/comp/threevirtues.shtml).

Lastly, It seems like you are siding favoring the bad UA's, instead of
just realizing that there is something dreadfuly _wrong_ with them.

-- 
Frank Tobin		http://www.uiuc.edu/~ftobin/

Received on Saturday, 3 February 2001 18:01:22 UTC