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

Return-Path: birk@bodega.stanford.edu
Received: by acetes.pa.dec.com; id AA03875; Thu, 24 Aug 95 17:04:16 -0700
Received: by pobox1.pa.dec.com; id AA22755; Thu, 24 Aug 95 17:04:09 -0700
Received: from bodega.Stanford.EDU by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)id AA19910; Thu, 24 Aug 1995 16:56:09 -0700
Received:  by bodega.stanford.edu (5.65/25-eef) id AA09233; Thu, 24 Aug 1995 16:56:13 -0700
Date: Thu, 24 Aug 1995 16:56:12 -0700 (PDT)
From: Yitzhak Birk <birk@bodega.stanford.edu>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Subject: Re: Proposal: a PLAY or STREAM method for http/1.1 
In-Reply-To: <9508242041.AA02691@acetes.pa.dec.com>
Message-Id: <Pine.ULT.3.91.950824153853.8194C-100000@bodega.stanford.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



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).

This can be handled by something like:
   <PLAY SRC="imp://www.unitedmedia.com/comics/dilbert/todays_song.au"
         ALT="http://www.unitedmedia.com/comics/dilbert/todays_song.au">
giving the browser a choice of mechanisms.

    For example, caches for the different protocols may wish to share
    data.

It's clearly possible to use one proxy to handle multiple protocols
(HTTP, Gopher, FTP, etc.) so adding one more protocol to the set
should not be impossible.  In other words, my proposal makes it
*possible* to share the cache between HTTP and IMP, just not *required*.

    I also expect any work on a separate protocol to take much longer
    than the inclusion of a minimal version of PLAY in HTTP.

Ever looked at the source code for an HTTP server or proxy?  Some
of them are pretty twisted.  I would bet that you could write a new
IMP server in less time than it would take to understand an existing
HTTP server.

And it will certainly be easier to write separate specs for IMP and
HTTP.  Especially because the working group is unlikely to support
putting an untested design into the HTTP spec.

-Jeff

Received on Thursday, 24 August 1995 17:21:23 UTC