- From: Yitzhak Birk <birk@bodega.stanford.edu>
- Date: Thu, 24 Aug 1995 16:56:12 -0700 (PDT)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Thu, 24 Aug 1995, Jeffrey Mogul wrote: > People will either use GET or they will use something different, > something that does not yet exist. You propose that the new thing > be a new method in HTTP. Others have suggested that the new thing > be a new protocol. Either way, there's a lot of new implementation > to do. > > I'd think about it this way. "http:" is just one of the things > a URL can start with; the world can already deal with that level > of choice. Is it better to add a PLAY method to HTTP, or perhaps > to invent a new "HTTP-like" protocol, say "IMP" (for "immediate > play protocol")? > > With IMP, HTML files would include both things like inlined images > <IMG SRC="http://www.unitedmedia.com/comics/dilbert/todays_dilbert.gif"> > and inlined "play now" things > <PLAY SRC="imp://www.unitedmedia.com/comics/dilbert/todays_movie.mpeg"> > <PLAY SRC="imp://www.unitedmedia.com/comics/dilbert/todays_song.au"> > although I imagine that the HTML design to take advantage of this might > be more complex. > > I suggest that using a new, separate protocol will make things > simpler, cleaner, and easier to implement: >... I understand the advantages of separating the effort for supporting PLAY from the HTTP standardization. However, the separation may not be as clean as it appears from your example. This is because PLAY/GET is a property of the request, not of the item being requested (though PLAY may not be relevant to certain item types). For example, caches for the different protocols may wish to share data. I can even envision cases in which a proxie responds to a PLAY request with a smooth stream, but sends on a GET request to the original server over a very-high-speed backbone. Can be done with separate protocols, of course, but perhaps more natural as a method-change within the same protocol. I also expect any work on a separate protocol to take much longer than the inclusion of a minimal version of PLAY in HTTP. This could subsequently evolve into a more powerful one with high-quality implementations or be succeeded by a separate protocol. I expect the traffic pattern on the network as well as server scheduling to be affected substantially even by the simplest form of PLAY whenever viewing of clips accounts for a substantial fraction of load. ------------------------------------- Yitzhak Birk EE Dept, Technion - Israel Inst. of Technology birk@ee.technion.ac.il Presently at HP Labs, Palo Alto. (birk@bodega.stanford.edu, birk@hpl.hp.com)
Received on Thursday, 24 August 1995 16:57:36 UTC