Hi all,
Here are my comments (marked "<MJ>") added to Michael Sweet's comments
(marked "MS>").
Marty Joel
"Hastings, Tom N" wrote:
> ISSUE 09: Make Event Wait Mode OPTIONAL for a Sender and a Receiver?
> Currently the spec REQUIRES the Receiver to support both values of the
> "notify-wait" operation attribute ('true' and 'false').
>> With the Notification Recipient being able to request the Receiver to
filter
> out duplicates, is it ok to allow the Receiver to always force the
> Notification Recipient back to Event No Wait Mode with the
> "notify-get-interval" operation attribute of when to poll next?
>> Of should Event Wait Mode be RECOMMENDED for the Receiver?
> What about RECOMMENDED for the Sender?
> ...
MS> I think event-wait-mode should be OPTIONAL but RECOMMENDED. There
will always be client and server implementations that can't do the
multipart encoding, or can't spare the extra socket resources.
MS> Since we already have defined the fallback behavior for both client
and server, this should not pose a problem.
MS> It might be useful to provide a new "notify-wait-supported"
attribute that the client can query with the Get-Printer-Attributes
request to see ahead of time if the server can support wait mode,
although with the caveat that the server may choose not to honor
individual requests in the interests of resource management.
<MJ> I like the idea of making Event Wait Mode RECOMMENDED for both the
Sender and Receiver. I don't know if notify-wait-supported is needed,
since I don't see how that would change the Sender's behavior. Does
the Sender care if it sends a request for wait mode and receives a
try-again time, versus sending a non-wait mode and receives a
try-again
time?
<MJ> Regarding the whole try-again time issue, I don't think the Receiver
should be sending that, and should indicate the desire to stop or not
start wait mode with a boolean or a status code. The Sender can do a
Get-Printer-Attributes to learn how long events are retained. The
Sender knows by when it must issue another Get-Notifications to avoid
the risk of losing events. If it isn't in keep-alive mode, the Sender
must take into account how long it might take to connect, so the
returning of the number of seconds to wait before trying again is
misleading.