Re: Point of order!

At 2001-02-05T07:18-0800, Dustin Kreidler wrote:-

> 1) Businesses are still forcing their clients to browse on
> older UAs.  As someone else pointed out, Mom and Dad have
> no clue how to upgrade their browser.  While I understand,
> and even join with you, in hating the current technology,
> pinning your "solutions" on future technologies is kinda
> like saying that the cure for California's power problems
> is the development of solar and wind power.  Tell that to
> the people with no lights.  They don't care about what you
> could do with 5 years and a great big budget.  Use what you
> have and fix it now.

This is true enough, depending on what you mean by '"solutions"', but not
a reason not to develop new technologies. No one is claiming that the mere
existence of (for instance) a W3C Recommendation is sufficient to make a
given technique appropriate for important web pages; any author with this
sort of attitude is greatly mistaken. What is being claimed is that
certain approaches would provide better solutions to certain problems than
are currently possible. Any new technology will initially be of only
experimental interest; when (and if) slightly better support appears, it
becomes useful in restricted settings (e.g. where choice of client is
already limited for other reasons, or where its effect cannot easily be
achieved by any other means); only with widespread support does it become
suitable for widespread use.

Consider, for instance, MathML. Development on MathML started several
years ago, and it addresses a significant problem: that of including
mathematical expressions in hypertext, in a way that is accessible and
allows for good presentation whatever the output medium. Even now, MathML
support is only just beginning to appear in the most popular browsers, and
it won't be possible to rely on it probably being present for some time
yet. This does not detract from the fact that it is a useful tool whose
development was worthwhile, even at the very beginning, when software
support was inevitably non-existent.

(In fact, in the case of external entities for client-side includes, the
technology is not new at all, considerably pre-dating HTML, but it is
nevertheless currently utterly unsuitable for the vast majority of web
pages, because there is next to no support for it. Even so, it is still
something that could prove very useful, and it is therefore perhaps worth
trying to persuade the browser authors that this is so - maybe after five
years it will be something we can reasonably use.)

> 2) As far as cached items go, I have NO idea what
> persistant connections do in terms of caching, but i do
> know that with limited hard disk space, most people who
> know just a little about the internet (the small amount of
> knowledge that makes them dangerous) clean up their caches
> on a fairly regular basis.  The common UA's have that as an
> easy to find option.  Assuming they will keep all the
> static elements of *your* site while discarding all of the
> ad crap they get dumped on them is ludicrous.  When
> everyone can own that cool 60GB hard drive, ok.  Fine.
> Cache all of your stuff to your hearts content.  But this
> is NOT the case for Mom and Dad.

Persistent connections don't affect cacheing at all - they just reduce the
number of connections the client has to make to the server (or proxy).
Cached material does indeed expire, and it would be silly to expect
particular sites to be given special treatment in this respect, but the
principal benefit of local cacheing is within a single "session": once the
browser has loaded the resources associated with the first page visited in
a particular website, they do not need to be downloaded again when they
are required on subsequent pages visited soon after. Client-side includes
in particular are likely to be things which are repeated often across a
website, and so are especially likely to benefit from cacheing. If the
user visits a certain site regularly it is quite likely that the files'
last-visited dates will be kept recent enough that they stay in the cache
more or less permanently (barring manual cleaning-out).

> I guess the real point is this.  For their benefit, never
> assume anyone has your knowledge or experience.  Case in
> point:
>   My car does not expect me to figure out exactly how much
> gas to put into the engine, or how much air to mix in, or
> how quickly to rev up the whole process.  I am presented
> with one pedal, and the car takes care of everything else
> for me.  If i were an engine engineer, i might yearn for a
> control mechanism that would be perfect for *me* to tweak
> the power and fuel consumption to my heart's delight.  But
> then, my Mom and Dad wouldn't be able to drive anywhere and
> get milk.  So what would be the point?

Knowledge and experience are not really the issue here. Why should the
ability to tweak power and fuel consumption preclude the presence of an
accelerator pedal working more or less as normal? The problems only start
when you expect any other car you might drive to carry this feature, and
run out of fuel. Even in a car with air conditioning, you can open the
windows; even in the newest HTML 4.0 browsers with frames and scripting
and goodness knows what else, old HTML 2.0 documents will be rendered
correctly. New technology does not immediately destroy old. New technology
is not worthless simply because it is not yet ubiquitous, nor because not
everyone will find it useful.

Tim Bagot

Received on Monday, 5 February 2001 13:37:25 UTC