P.S. I don't mean to convey the impression that notifications must be
aligned on chunk boundaries. It's just that chunking is important for this
application since the Content-Length is difficult to determine in advance.
So, if you are cranking out a lot of page-level notifications on a 1000 PPM
printer, I don't see any problem with putting multiple notifications in one
P.P.S. As I mentioned earlier, the buffering proxy is a mythical beast.
Server builders abhor the possibility of infinite buffers.
---------------------- Forwarded by Carl Kugler/Boulder/IBM on 08/22/2000
02:57 PM ---------------------------
From: Carl Kugler on 08/22/2000 02:54 PM
To: "Herriot, Robert" <Robert.Herriot at pahv.xerox.com>
cc: pmoore at peerless.com, Harry Lewis/Boulder/IBM at IBMUS,
bwagner at digprod.com, ipp at pwg.org
From: Carl Kugler/Boulder/IBM at IBMUS
Subject: RE: IPP> machine readable etc. - why Harry is right (Document
link: Carl Kugler)
"Herriot, Robert" <Robert.Herriot at pahv.xerox.com> wrote:
>>> -----Original Message-----
>> From: Carl Kugler/Boulder/IBM [mailto:kugler at us.ibm.com]
>> Sent: Tuesday, August 22, 2000 12:52 PM
>> example, you do a Print-Job request, and get back a chunked
>> response. The
>> first chunk contains the normal Print-Job response. Additional chunks
>> follow (later), containing notifications about the job
>> progress. This is
>> efficient enough for page-by-page notifications.
>>But would the chunks be so conveniently divided in an off-the-shelf web
Well, I don't know of any off-the-shelf web server that supports IPP. So
then it's going to depend on the IPP implementation and the server APIs:
CGI, Servlet, NSAPI, ISAPI, whatever. Those APIs that support chunked
responses tend to emit a chunk for each write() on the API, so the IPP
implementation could divide up the chunks this way. It doesn't really
matter too much though. You might see some "jitter" in the timing of the
notification deliveries. Worst case, with the buffering proxy, you get the
entire Job history in one big blob.