Re: HTTP: T-T-T-Talking about MIME Generation

On Fri, 16 Dec 1994, John Franks wrote:
> Correct me if I am wrong, but I concluded from Spero's postings that
> nothing currently proposed including MGET, hold-open, or even HTTP-NG
> would improve (or even match?) the user's perceived performance
> currently given by Netscape.  By this I mean the ellapsed time until
> the user can start reading *all the text* and the ellapsed time until
> the user can jump to a new link.

Actually I concluded that only -ng would give the same performance.  The
session layer would allow for parallel downloads over the same connection,
effectively the same as the multiple-TCP-connections in NetScape.  In fact it
could provide a speed increase over NetScape in a couple ways - in addition
to the benefit gained from not having to open all those TCP connections, the
server could also start sending inlined images before the client knows it
wants them, giving the client the option of cleanly aborting them if it knows
it already has them cached locally. 

> It seems to me that this "user's perceived performance" or UPP is going
> to be the dominant consideration for commercial client developers.  If
> they can't match Netscape they simply won't be viable.  Accordingly I
> strongly suspect that in six months all the major vendors will be doing
> what Netscape is doing today.  I don't see that they really have a choice.

If it's rendering-while-downloading, great, that needs to be done (the 
new MacWeb does that, as do a few others).  If it's multiple connects, 
let's hope not.

If a SESSION method is easy to implement for HTTP 1.1, let's do it and 
not worry about MIME multipart messages (putting that effort instead 
towards -NG).

As a content-provider that gets 300,000 hits a day, as soon as there is 
an implementation of SESSION or MGET for any of the full-feature servers 
(NCSA or WN) that is mirrored by a few browsers out there I'll install it.

> And I don't see this as really bad.  I know the Netscape technique will
> put a heavier load on network bandwidth, and maybe will stress some 
> servers.  As Spero pointed out there are many aborted connections as
> users jump to a new document without waiting for the current one to
> completely download.  But all that is the price we pay for quality service
> (from the user's point of view).

The user isn't the one paying that price, though.  

> I guess the bottom line is that there is not much point in changing
> HTTP unless the resulting protocol can (1) at least match the Netscape
> UPP, and (2) simultaneously significantly improve network efficiency.

For rendering-while-downloading browsers, MGET will improve performance 
overall - the UPP performance will only be improved if the person uses 
the Netscape-only WIDTH and HEIGHT attributes to the IMG tag so the page 
can be laid out before the latter image retreivals have even begun.  It's 
precisely because NetScape can fetch the first few bytes of many inlined 
images that it can calculate how to lay out the page without having to 
adjust layout later.  Since -NG will allow the layout-specific info in 
the first few packets, it will improve both UPP and overall speed.


Your slick hype/tripe/wipedisk/zipped/zippy/whine/online/sign.on.the.ish/oil
pill/roadkill/grease.slick/neat.trick is great for what it is. -- Wired Fan #3

Received on Friday, 16 December 1994 12:19:07 UTC