IPP> NOT - More about ISSUE 08: Sender MAY include list of subscription ids and sequence numbers

IPP> NOT - More about ISSUE 08: Sender MAY include list of subscription ids and sequence numbers

McDonald, Ira imcdonald at sharplabs.com
Tue Jul 31 11:17:23 EDT 2001


Hi Michael,

But when you ask for events by (only) "notify-recipient-uri",
you are certain to get duplicates (because your polling interval
MUST be shorter than the event persistent, in order for polling
to work at all).

The explicit list of pairs of subscription-id and sequence-number
allows duplicate avoidance.  Now you see why the optimization?

Cheers,
- Ira McDonald

-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Tuesday, July 31, 2001 11:18 AM
To: McDonald, Ira
Cc: Hastings, Tom N; ipp (E-mail); ipp at webpageassembler.com
Subject: Re: IPP> NOT - More about ISSUE 08: Sender MAY include list of
subscription ids and sequence numbers


"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



More information about the Ipp mailing list