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

    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.

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:
(1) We won't have to figure out how PLAY interacts with the rest
of HTTP.
(2) People can start working on prototype implementations of IMP
in parallel with current and future standardization efforts of HTTP;
it's a mistake to include an untested feature as part of the revision
of the standard for a heavily-used system.
(3) Proxies would have to be written or rewritten in either case,
so why not just write a separate IMP proxy that knows how to deal
with multiple immediate-play streams, and may have to have a completely
different caching approach.
(4) Some existing HTTP servers are a real mess inside.  It might be
hard to fix them to make PLAY work well.
(5) People who want to use a specific HTTP server could get their
IMP server from some other source or vendor.
(6) IMP could avoid some of the baggage that HTTP is stuck with
(including, perhaps, single-use connections, ASCII headers, etc.)

I'd bet that you could write an IMP server and modify a browser
to support IMP with far less effort than it would take to convince
the HTTP working group to add PLAY to HTTP.

-Jeff

Received on Thursday, 24 August 1995 13:57:16 UTC