It looks like it would entail a lot of round-trips - especially
if using polling with timeout. Is such an elaborate mechanism
really needed? i.e. do you need to be able to continuously change
the set of events to which you're subscribed ?
I also don't think I like the idea of defining new methods for this purpose.
if you're going to require new proxy/firewall code, you are probably
better off using a new protocol that is designed with this purpose in mind.
> Do you think that IPP should support both an http mechanism (such as the one
> described in the IETF draft) and a tcp one, where the receiver listens on a
> port?
no. I think it should be either one or the other. if HTTP is not
suitable more-or-less as-is (probably without adding any additional
methods) then you should use another protocol based on TCP.
> At the IETF IPP session, we discussed congestion control as a reason for
> preferring TCP over UDP, but you didn't mention in your email. Do you still
> believe that it is a reason to prefer TCP, at least for the page completion
> case.
congestion control is a clear advantage of TCP, but congestion
control is not really needed if the data rate is inherently low.
if the protocol batches notifications and limits the rate of
update to, say, once every several seconds, TCP congestion control
would be unlikely to result in any change to that data rate.
and if you do more frequent notifications, the last thing you
want is TCP congestion control slowing them down.
on the other hand, if TCP congestion control causes the updates to
be delayed so much that they get transmitted more slowly than they're
generated, what you get is probably not what you wanted to happen.
so you would rather slow down the generation and compress
or batch the notifications, than have TCP slow down the transmission.
Keith