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

According to Dave Kristol:
> 
> "Daniel W. Connolly" <connolly@hal.com> wrote:
> 
>   > Deploying MGET/multipart looks to me like:
>   [a list of steps for clients, servers, including...]
>   * A few information providers maybe start using it
> 	  (It's 3 months into the future by now)
> 
>   > 
>   > Meanwhile, commercial folks are implementing HTTP-NG at lightning
>   > speed. Six months from now, all the major vendors are doing
>   > interoperable compression and encryption over something like SCP or
>   > SSL (not to mention strong authentication).
> 
> Sorry, I'm skeptical about this statement.  At least some of the
> proposals for MGET/multipart and keep-alive are compatible with what
> exists now.  For example, a client could attempt to send an MGET to a
> server.  If the server chokes, the client can revert to a series of
> regular GETs.
> 
...
> 
> So, I think vendors are less likely to switch to HTTP-NG in three
> months, a protocol still being experimented with and IMO not quite
> ready for prime time, than they are to adopt the MGET stuff.

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.

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.

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).

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.


John Franks

Received on Friday, 16 December 1994 07:11:23 UTC