I agree, fitting status messages into the current protocol will either be an
ugly hack, or require two responses like in the 205 proposal. I'm not fond
of either.
* 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.
This is an interesting proposal, and very open-ended which is why I like it.
It provides flexibility in that the Services: line could specify anything
(like the access authorization does now, the PEM and PGP experimental auth
protocols I just added to Mosaic and httpd are remarkably similar to this
proposal but I digress). Of all the proposals made thus far, this sounds
like the most logical. I think we should be looking at long-term solutions
instead of short-term HTTP hacks and kludges so we're not regretting our
actions five years from now.
* 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.
*/
CGI will help in that the Status: line could be made available in the
environment for the gateways to interpret. This raises the question again of
whether CGI should send all of the header lines to the script regardless of
whether it knows their meaning, but that will require more thought.
--Rob