W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

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

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
Message-Id: <Pine.ULT.3.91.950824153853.8194C-100000@bodega.stanford.edu>


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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:26 EDT