"McDonald, Ira" wrote:
> ...
> <ira> Marty describes the following scenario. A Notification
> Recipient (NOT the job originator, maybe your secretary)
> issues Get-Subscriptions with a known "notify-recipient-uri"
> (e.g., your secretary's 'mailto:' address in 'ippget:' form).
> Subsequently this Notification Recipient issues periodic
> (polling) Get-Notifications with the explicit list, but wants
> to ALSO find any new subscriptions.
>> <ira> I'm not entirely sure I like this optimization. At any
> point, this Notification Recipient can re-issue Get-Subscriptions
> and do the search. Adding the optional search (even when the
> "notify-subscription-ids" operation attribute is supplied) seems
> like a questionable optimization to me. I think this kind of
> "third-party" Notification Recipient (not the job originator)
> should probably do periodic Get-Subscription operations anyway.
MS> I'd recommend that we just support the notify-subscription-ids
OR notify-recipient-uri attribute to select subscriptions, and
REQUIRE the server to reject a request containing both
attributes with a client-error-bad-request error status.
MS> If you add the optional search stuff, then having the
notify-subscription-ids attribute for Marty's scenario
is of no benefit - the subscription IDs will almost
certainly be a subset of the subscriptions with the
specified recipient URI, and you've just forced the
server to lookup the same subscriptions twice... Better
to use Get-Subscriptions or always ask for events by
recipient URI (which should pick up on any new subscriptions
in wait mode, right? :)
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com