Re: Protocol Benchmarking (with Accept examples - long)

• Mail folder: WWW Talk Jan 94-present
• Next message: Alexander G. Smith: "Re: Motif 1.2.2 lock up problems."
• Previous message: Monica Cucoanes: "Re: CEPES Publications"
• Maybe in reply to: Ari Luotonen: "Re: Protocol Benchmarking (with Accept examples - long)"
• Reply: Lou Montulli: "Re: Protocol Benchmarking (with Accept examples - long)"

Errors-To: secret@www0.cern.ch
Date: Thu, 3 Feb 1994 16:26:34 --100
Message-id: <9402031524.AA23715@void.ncsa.uiuc.edu>
Errors-To: secret@www0.cern.ch
Reply-To: www-talk@www0.cern.ch
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: atotic@ncsa.uiuc.edu (Alexsander Totic)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Protocol Benchmarking (with Accept examples - long)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 837

> Correct me if I'm wrong but currently we send Accepts in a single outward
> call and get some form of result (either the document or an error)
> returned from the server.  With your scheme we send a request, receive a
> list of possible types, send back a request for types the client can
> handle and then get the reponse from the server.  Therefore we've gone
> from one round trip delay to two.  Thus to save transmitting a few bytes
> we take an increased latency hit.  Right?

I was thinking of sending only types that client can handle internally (GIF,
HTML, XBM), in the first request. Only if the requested file is an "unusual"
type, handled by external apps, would the second trip be necessary. This scheme
assumes that for a while, clients will to handle a few types internally, and 
a large number of external types.

Aleks