[11297] in Commercialization & Privatization of the Internet
Living on the tiles (was Re: How Long to a Multimedia Internet?
daemon@ATHENA.MIT.EDU (Paul Robinson)
Mon Mar 28 15:38:40 1994
Date: Mon, 28 Mar 1994 04:44:28 -0500 (EST)
From: Paul Robinson <PAUL@tdr.com>
Reply-To: Paul Robinson <PAUL@tdr.com>
To: tenney@netcom.com, Everyone Else Lurking on Com-Priv <com-priv@psi.com>
>From: Paul Robinson <PAUL@TDR.COM>
Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
-----
tenney@netcom.com, writes:
> At 11:42 AM 3/23/94 -0500, Walt Howe, DELPHI Internet SIG
> Manager wrote:
>
> > What I find missing from the discussions of the attractiveness
> > of Mosaic as an interface via dialups to shell accounts or
> > SLIPs is the unattractiveness of 14.4K access. Once you get
> > past the stage of marveling at the graphics, the 2 to 5 minute
> > wait between graphic pages, gets old very fast. Mosaic will be
> > nothing more than a curiosity to most people who are
> > restricted to current dialup speeds. The bandwidth of the last
> > leg to the home or office remains critical.
>
> There is another way of looking at the problem for which your
> last sentence was an answer...
>
> Mosaic was not designed to be a commercial product. Mosaic
> was designed for a university lan running at Ethernet speeds.
> What has, and always will remain critical, is the well thought
> out experienced design that balances performance and features
> against the needs of the consumer.
>
> There aint no such thing as enough bandwidth or memory --
> period.
You forgot to add "disk space". Oh, I'll do my "enough" comment later.
> So, instead of your answer that bandwidth is the critical need
> here, I maintain that industrial-grade well designed software
> (and protocols) are the underlying solution. I believe that
> Mosaic (internally especially) would be very different if it
> had been designed for 14.4kb instead of Ethernet speeds...
One of the things that it was discovered on IBM Mainframes running the
CICS transaction monitor was that by adding a traffic monitoring program
they got better performance by having the monitor map the screen
internally and only send to the terminal what had changed.
This is on a character-based terminal application running at 9600 baud.
They got impressive improvement in their terminal response - by
eliminating unneeded data transmission.
So it applies here. If something like Mosaic had been designed for a
slower terminal line, it would have been designed so that it would only
send data as things changed, would send and use line drawing and area
drawing primitives such as squares, rectangles, circles or whatever, would
have standard defined fonts and so on. So that you send as little
information as you can, and only when you have to. This allows you to
effectively increase the bandwidth. But you have to design for that.
This is one of the reasons I don't like the newer computing systems with
10+ meg of memory and 200+ meg disk. It teaches programmers that being
slothful and wasteful of resources is okay since people will throw more
and bigger hardware at the problem. The answer should be to solve the
problem in a more resource-thrifty manner, than to waste resources.
---
Paul Robinson - Paul@TDR.COM
Voted "Largest Polluter of the (IETF) list" by Randy Bush <randy@psg.com>
-----
The following Automatic Fortune Cookie was selected only for this message:
If at first you don't succeed, give up, no use being a damn fool.
