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
HTTP chunk.
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@pahv.xerox.com>
cc: pmoore@peerless.com, Harry Lewis/Boulder/IBM@IBMUS,
bwagner@digprod.com, ipp@pwg.org
From: Carl Kugler/Boulder/IBM@IBMUS
Subject: RE: IPP> machine readable etc. - why Harry is right (Document
link: Carl Kugler)
"Herriot, Robert" <Robert.Herriot@pahv.xerox.com> wrote:
>
>> -----Original Message-----
>> From: Carl Kugler/Boulder/IBM [mailto:kugler@us.ibm.com]
>> Sent: Tuesday, August 22, 2000 12:52 PM
>> For
>> 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
>server?
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.
-Carl
This archive was generated by hypermail 2b29 : Tue Aug 22 2000 - 17:21:32 EDT