pipelining vs. deferred content

John Franks writes:
> When pipelining is used there is no functional difference between <img
> src="foo.png"> and the <img src=deferred id=ID> you suggest.

I believe there is a difference.  Pipelining means the client issues
"multiple requests without waiting for each response" [RFC 2069] and the
server sends them back in order on the same connection.  This is useful in
retrieving the set of inline images in a static document, for example.

I'm suggesting something else: the client has requested an object that will
take a non-zero amount of time to generate, such as a map, a visualization,
or the result of a database query.  The generator can either wait until the
image is done and send HTML referencing it, or immediately send HTML
referencing a script which generates image data, as in <img
src="image_making_script.cgi">.  In the former case, the client waits while
the server grinds away and eventually spits out HTML and the image it
references; in the latter, the client gets something to display while the
server is working.  This lets some of the response be transmitted during
otherwise idle time and is friendlier from the user-interface point of view.
The big disadvantage of the method is that it requires a second script to be
invoked on the server, which is why I avoid it.

My proposal is that the server say, in effect, "Here's your page; reserve
space for an image and wait just a sec until I give you something to fill
the space."  The same CGI generates all the content, providing sub-headers
as appropriate to demarcate each piece.  The client issues a single GET or
POST instead of pipelining multiple requests.

I don't believe pipelining handles this situation.  Hacks like
image-emitting CGIs and <frame>s that reference scripts can create the
desired effect but at a cost to the network and the server.

--Jeff dLB


  = J-F Pitot de La Beaujardiere
  = delabeau@iniki.gsfc.nasa.gov
  = http://globe2.gsfc.nasa.gov/

Received on Wednesday, 26 March 1997 12:58:55 UTC