[11368] in Commercialization & Privatization of the Internet
Re: How Long to a Multimedia Internet?
daemon@ATHENA.MIT.EDU (Christopher Davis)
Wed Mar 30 14:09:11 1994
Date: Tue, 29 Mar 1994 14:19:53 -0500
From: Christopher Davis <ckd@kei.com>
To: tenney@netcom.com (Glenn S. Tenney)
Cc: Christopher Davis <ckd@kei.com>, com-priv@lists.psi.com
In-Reply-To: <199403290157.RAA07898@netcom9.netcom.com>
GST> == Glenn S Tenney <tenney@netcom.com>
GST> If there is so much manual intervention required to set up an
GST> efficient http package, then it was not well designed for this use.
GST> ie., it works, but everything's not a nail... :-)
It is easy to make an efficient HTML page. Simply keep the information in
small chunks. This is how hypertext is supposed to work in the first
place, after all. It is also easy to make an inefficient HTML page.
Simply add a huge inline picture, such as a very pretty 120K GIF of your
campus.
Note, however, that all the browsers I've seen allow you to delay or
completely inhibit the loading of inline images.
GST> A well designed piece of software for such applications would take
GST> into account varying bandwidths, etc. and come up with automatic
GST> ways to either make the task much easier (so people would be
GST> inclined to use those tools), or automatic ways that DO it for you
GST> (so that once an http package was defined, it would work very well
GST> automatically on low speed lines).
If the browsers had some good way of automatically detecting SLIP lines
and defaulting to delayed image loading, that would be useful. Other than
that, I can't see any really GOOD solution. The HTTP HEAD method allows
the browser to check the size of an item before downloading it (if the
server supports it); this is used under Mosaic/X 2.2 to give a "xxx of
xxxxx bytes" display. It could also be used to, say, auto-load only
inline images below 32K in size.
