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

-- [ From: Bob Wyman * EMC.Ver #2.5.02 ] --

> Clearly, it is always possible to define another protocol and use it to
get
> things done. I nonetheless still argue that the semantics of PLAY should
be
> "native" within HTTP, for reasons that have to do with the way in which
HTTP is
> commonly used and its own performance:

HTTP performance issues can certainly be solved independent of the
introduction of PLAY. 

> - HTTP is commonly used for viewing items, some of which are retained by
the
> client.

This business of "items... which are retained" is a very important point.
That is, HTTP is typically used to transfer contained objects around the
network. Objects which have size, creation dates, etc. In fact, it isn't
only clients that retain these objects but also a variety of proxies, caches
, HTTP accelerators, etc. PLAY requires a completely different beast to be
supported.

It is important to consider the entire system here -- not just the one
component which is the HTTP protocol. Unfortunately, we don't have a
detailed reference model to show all the components, however, we all know
that the "system" which is the Web contains proxy-caches and HTTP
Accelerators...

What should a proxy-cache or HTTP accelerator do with a PLAY stream? Do we
really want to bog down these servers with the task of shovelling non-
cacheable streams across the network? Do we really want cache implementors
to have to address the service level requirements of the streams that are
looping through them? Isn't it reasonable to assume that streams would
perform better if they didn't pass through the same caches and proxies that
are designed for objects of finite dimensions?

I would suggest that the cache problem alone would be enough to want to put
streams on a different port or channel than that which is used for the kinds
of objects that HTTP transfers today.  There are other good arguments as
well...

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

As mentioned before, HTTP performance can be improved and is being improved
without introducing PLAY. It would seem that the "performance improvement"
you are discussing would only really be provided to users of streaming
applications.

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

If solving these problems for streaming applications is an important problem
, people will inevitably and eventually get together to build a solution.
They will, in fact, probably end up building a better solution than would
arise from tacking something onto the side of HTTP. Because the semantic
requirements of "documents" and "streams" are so different, whatever comes
out of a joint effort is likely to make users of either application type
very happy. We'll then find ourselves in interminable arguments between the
"stream" people and the "document" people. The tremendous amount of
discussion concerning building state into HTTP (for shopping bags, etc.)
would probably be nothing compared to what would result once PLAY shows up
in HTTP.

		bob wyman

Received on Thursday, 24 August 1995 14:28:54 UTC