I felt that the nail in the coffin of multi-part response was the radical change
in the data flow - it was too much of a change (at least to my mental model of
IPP).
Regarding the problems you cite
1. What is a buffering proxy. If it doesnt allow what I described then it will
break instant messegner systems and hence wont survive in the market place very
long. IN fact this proposal has the same requirements as instant messgener
systems (and they definitely work).
2. Ditto
3. What does that means -proxies are limited to 2 per server (by spec). Do you
mean HTTP proxies? Well this wont be using HTTP proxies - they will have to be
direct (socks or winsock) proxies.
4. is a good point. But then the printer probably isnt going to have a lot of
clients talking directly to it.
"Carl Kugler/Boulder/IBM" <kugler@us.ibm.com> on 08/22/2000 09:35:44 AM
To: pmoore@peerless.com
cc: "Harry Lewis/Boulder/IBM" <harryl@us.ibm.com>, bwagner@digprod.com,
ipp@pwg.org, "Herriot, Robert" <Robert.Herriot@pahv.xerox.com> (bcc: Paul
Moore/AUCO/US)
Subject: RE: IPP> machine readable etc. - why Harry is right
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
This archive was generated by hypermail 2b29 : Tue Aug 22 2000 - 13:10:24 EDT