> I don't like this example (of using GET for printer status)
> without any cache-control headers, and with the presumption
> that the entity body is streamed with indefinite pauses.
understood. I realized that such headers would be needed when
I wrote the example, but am not so intimately familiar with
HTTP that I could cite them off the top of my head; and I didn't
want to take the time to look them up on a Friday night. sorry.
I suspect that few present-day proxies will want to buffer the entire
response before relaying it to the client, because buffreing the
entire response is now known to a significant and very annoying affect
on response time.
at any rate, to the extent that we believe that this technique won't
work, then to me that is a good reason to abandon the idea of using
HTTP for printer notifications.
> Also, the URI has a problem:
>> /printer/status/job#2343
>> Since '#' is a reserved character for fragment delimiter, and
> HTTP URIs don't de-encode the data, this is not a good example.
right you are.
Keith