- From: Dave Kristol <dmk@allegra.att.com>
- Date: Thu, 24 Aug 95 17:06:12 EDT
- To: birk@bodega.stanford.edu
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Yitzhak Birk <birk@bodega.stanford.edu> wrote: > [...] > In summary, I argue that the PLAY semantics for streaming (as opposed > to truly interactive conferencing) do fall well within the natural > scope of HTTP, even for its current mainstream use, and believe that > their inclusion in HTTP would facilitate substantial and meaningful > performance improvements. In the absence of PLAY, I suspect that people > will simply continue using GET rather than develop a new protocol for > a subset of "HTTP-like" requests, and overcoming the resulting > performance problems will be more difficult. I don't believe you can negotiate all the flow parameters in advance, because the state of the network changes, and the changes affect the streaming. Thus it's likely there will be two-way communication between client and server to adjust the data rate. HTTP is ill-suited for such communication. People here at Bell Labs have done some work on real-time delivery over the Internet. (See <http://www.research.att.com/~hpk/nemesis.html>.) They use a separate connection in an outboard application, which was the basis for my earlier description. I see that superficially the PLAY method fits into the HTTP paradigm, but I think the details make the fit a poor one. Adding a bunch of new headers, and possibly client-directed flow control, means you're a good way toward a very different protocol. So make it a different protocol! Dave Kristol
Received on Thursday, 24 August 1995 14:16:41 UTC