>It's not clear to me at this point
>that "Status:" is the right solution, HTTP is simply not designed as an
>interactive protocol TTBOMK.
It's fairly clear to me that it is _not_ the correct solution. I was
thinking along the same lines as Tony w/ regards to using a separate
UDP connection.
Maybe I was just missing something, but I didn't see how either of
the initial suggestions would actually work.
The first method forced all of the status info to come before any of
the data was transferred which seems silly. If I have a server
generating information, it may as well be sending it as it is generated.
The second method, I don't understand at all. I've already received one
HTTP/1.0 response so how/where am I getting the "HTTP/1.0 205 Starting
search..." messages?
>
>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.
Agreed. It is silly to use TCP for information which is obviously
ideally suited for UDP.
-Jon
--- Jon E. Mittelhauser (jonm@ncsa.uiuc.edu) Research Programmer, NCSA (NCSA Mosaic for MS Windows) More info <a href="http://www.ncsa.uiuc.edu/SDG/People/jonm/jonm.html">here</a>