Re: Proposal: a PLAY or STREAM method for http/1.1

Yitzhak Birk <birk@bodega.stanford.edu> wrote:

  > [...]
  > In this note, I propose to add a "PLAY" (or "STREAM") method to
  > http/1.1 in support of data-streaming applications.  My proposal is
  > stated briefly, followed by FAQ (by me, so far...) which expose my
  > rationale. I am looking forward to comments on the proposal,
  > alternatives, as well as suggestions for appropriate attributes.
  > 
  > -----------------------------------
  > 
  > PROPOSAL:  add a "PLAY" (or "STREAM") METHOD to HTTP/1.1
  > 
  > The semantics of GET are "provide the requested entity in its entirety
  > as soon as possible". Various qualifiers may influence the content,
  > but the basic semantics remain unchanged.
  > 
  > The semantics of PLAY are "provide the requested material at the
  > suitable rate for playback, starting as soon as possible".  
  > [remainder deleted]

IMO, this kind of method is outside HTTP.  I think it is best handled by
(conceptually, at least) an outboard application, as follows:
	1)  user agent -> origin server
		Request stream entity
	2)  origin server -> user agent
		Here's identifier for entity
	3)  user agent creates (possibly) separate process, handing the
		identifier to it
	4)  separate process examines identifier, connects to (possibly)
		separate entity server
	5)  separate process and entity server negotiate bandwidth, etc.
		and commence to handle stream

HTTP is not all things to all people, and I think one of the things it
is not is a real-time transport protocol.  It seems to me much better
to segregate such sophisticated real-time processing elsewhere.

Note that, in my description above, there's no requirement for the process
or entity server to be different from the user agent and origin server.
But there's no requirement that they be the same, either.

Dave Kristol

Received on Thursday, 24 August 1995 06:24:48 UTC