One key problem with the WWW model is how one can add real time media. Currently, the access protocol model is based on the libWWW RPC approach, where a retrieval is initiated by the request, and the client cannot start displaying the result until the return.
Clearly, if the returned data is very large, then this may be inappropriate (see below). However, if the returned data can actually be played as it arrives (e.g. it is audio or video or similar data) then this is clearly not the right way to do things. Netscape does this to a certain extent, but only so that it can interleave GIF and text rendering.
Two approaches suggest themselves:
The latter approach is particularly inviting when one considers some of the ways Internet access may be provided in conjunction with CATV: It is quite possible to deliver broadcast quality TV down current copper twisted pair phone wire, up to modest distances, so long as one uses nearly all the bandwidth in one direction. So one could use a second, low bandwidth return channel for HTTP access, and return high quality TV to the client player. One can envisage other networks where bandwidth is asymmetric, or else there are other technical reasons to separate out channels for delivery of data requests and responses from real-time delivery (or transmission).