I'd consider HTTP a "monodirectional" in the sense that only the
browser (client) may initiate a communication to the server; the
server cannot initiate a transmission to a specific browser until
that browser opens a TCP connection to the server. HTTP specs
states clearly that it is a request-response protocol; a protocol
to transmit a request sent by the browser and to return a response
generated by the server, within one TCP session (ie. prior to the
connected socket being closed by either party). While TCP is
a full duplex channel, the fact that only the server and not the
browser provides a listening port means that no one can ever
initiate a connection to a browser. So without making the browser
install a listening port, it's hard to expect a browser to receive
unsolicited information.
On the "interactivity" issue, it is not HTML that needs to be
interactive, but more on the system that comprises the HTTP server,
the browser and the network. Interactivity, as I see it from the
perspective of my problem on hand, allows a person to initiate a
talk to another person via the server. Since a person runs a client
(browser) to talk to a server which will in turn initiate a
channel to another person's client browser, it is inherent in this
set up that mechanisms are needed to identify any specific instance
of browser, and for the browser to have the ability to "receive"
incoming calls via the provision of a browser's listening port.
On the comment about "I'm busy reading a document when a server
decides to interact with my browser", I prefer to look at the
issues separately. That a browser equipped with a listening socket
and so may be sent with unsolicited data does not imply that the
browser cannot decide how best it may present the data to the user.
It may prompt the user, or allow the user to turn off the line,
just like you may pull your phone off the wall to stop annoying
calls. But the presence of an underlying mechanism that allows
incoming calls to the browser is important to interactive applications.
On the CCI issue, the web page on CCI seems to be uncertain about
how a browser should select its port for applications to communicate with
it. The service offered by the browser in this case is also slightly
different. The applications manipulate the browser and makes use
of its HTML rendering capability and HTTP retrieval capability to
perform additional services. This is unlike allowing a remote
server from sending in unsolicited information to the browser
(A user would not want his/her browser to be manipulated by an
external server without control). Also, if a browser or CCI-application
uses a fixed port, no other browser may run with CCI capability.
Scripts and CCI-based services address a different requirement,
which is to provide "value-added" or intelligent processing and
making use of browser's display, URL and HTTP-aware capabilities
to achieve those services. It still does not allow a server to
inform a particular browser its intended messages.
On Netscape's PullPush mechanism, the server basically holds on to
the TCP channel which a connecting browser has established in
expectation of more data to be sent to the browser. The channel
is held open as long as the server thinks there is more data that
it may soon send, regardless of whether there is anything to be
sent through the channel at the moment. Once again, it is not
"interactive" in that the server may not initiate a communication
to the browser once it allows that channel to be closed. It is
an attempt, I'd consider, to do-away with the "interactivity"
issue by exploiting TCP's duplex channel.
The ability for a browser to be interactive does not also imply
that the browser should be conference-capable. Using the example I
gave in the previous mail, a long server search may first acknowledge
the browser's request with a short document, and subsequently,
when the search is concluded, initiation transfer of the results
to the browser. This is not conferencing, but interactivity.
It is a phenonmenon for WWW to have come this far. Interactive
browsers need not always be involved in interactive transactions;
it may disable its incoming port to behave like the current
browsers. But if browsers can listen, it will mean that information
can seek users instead of making users seek information.
As usual, this is purely discussion on the points made and no personal
feelings should be attached. Please share if you have a different
opinion so others, myself included, may also benefit from learning.
Afterall, that's why we're all here :)
I've made MOLTIP-UID and R-HTTP specifications available at
http://www.ncb.gov.sg/staff/cheekai/html/moltip-techspec.html
Chin Chee-Kai
http://www.ncb.gov.sg/staff/cheekai/