[I *wish* I had been able to participate in the phone conference;
unfortunately I was stuck in another meeting...]
mjoel at netreon.com wrote:
> ...
> I argued about this for a while in the teleconference call. It seemed to
> me that the client needed to know when it got the end of the bytes of an
> event notification attributes group. It turns out that Get-Notifications
> with waiting requires the use of HTTP 1.1's chunking. Each returned chunk
> will contain 1 or more event notification attributes groups (although I
> expect that for most implementations it will only be 1).
OK, this needs to be explicitly spelled out in the spec - some
implementations (CUPS included) will buffer a certain amount of data
(for CUPS it is 64k) and if the attributes in the buffer exceed the
size of the buffer, you have to write a chunk containing the data
so far and then continue filling the buffer with more data.
This could potentially mean that event notifications could end up in
multiple chunks, so the spec should specify that event notifications
cannot span multiple chunks, and maybe set a maximum size for the
notification data...
> ...
> notify-get-interval attribute, and an end-of-attributes-tag. Any function
> that does encoding must now be told if it should build a complete reply, a
> first chunk, an intermediate chunk, or a last chunk. On the client, when
> it issues Get-Notifications with waiting, it needs to be prepared to
> receive the HTTP chunks.
As long as the boundaries of each event are clearly delineated, the
client implementation shouldn't be too bad. The server, on the other
hand, will be more difficult to implement...
[FWIW, multi-part encoding would make this a whole lot easier!]
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com