Paul wrote:
>...
>>There are two workable possibilities - one is ipp-get. This already exists but
>is polling - and people have a visceral dislike of polling to say the least!
>It is a little better than polling, in that it introduces some message
queuing. With Get-Job-Attributes polling, you just get a periodic snapshot
of the state. With ipp-get, you can reconstruct the sequence of events
(e.g., Job history), even if you don't get them in real time.
>The other alternative is a tweak to indp. Instead of the client sending in a url
>and the printer connecting to that URL we could have a client-opened connection.
>>i.e. the client opens the connection
>it subscribes on the 'normal' operation url,
>in the subsription the notification url is 'indp:'
>the lack of an address in the url causes the printer to use the exisitng
>connection rather than open a new one.
>This solution has all the problems that killed the multi-part response solution:
1. Buffering proxies. (Although I strongly doubt their existence.)
2. Proxy time outs. (Although this could be handled with reconnects and sequence numbers.)
3. Proxies being limited (by spec) to two(?) connections to any particular server.
4. Tiny printers that can't handle more than a few active connections at a time.
Ipp-get might be as good as it gets.
-Carl