My current thinking on this general problem is that we need "protocol
callbacks", reply addresses for services provided by the client encoded
in the client's request to the server. For example, status messages could
be passed back via:
Services: Status/1.0 port=9994
Or, you might have the status monitor on another host:
Services: Status/1.0 port=9994,host=otherhost.dom
Or support an interactive audio/video service:
Services: AVsync/1.1 port=9995,chn=32,mode=HDTV.3
The status service should probably be UDP based, another reason
not to run it inside HTTP.
We could/should also define an interface standard for clients wanting to
run these services externally so, e.g., you could just get the AVsync
program and "hook it up" to your favorite client. Much thought still
needs to go into this, of course, but it seems a must for the long term.
Same goes for external content-type viewers. We need a high-end interface
language for talking about Hypertext objects between the client and
the viewer.
CGI has been a step in the right direction for the server end. Much
thanks to RobM for his effort there.
--sanders