IPP Mail Archive: Re: IPP> NOT - More about ISSUE 08: Sender

IPP Mail Archive: Re: IPP> NOT - More about ISSUE 08: Sender

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

From: Michael Sweet (mike@easysw.com)
Date: Tue Jul 31 2001 - 11:46:38 EDT

  • Next message: Hastings, Tom N: "RE: IPP> NOT - ISSUE 05"

    "McDonald, Ira" wrote:
    >
    > 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?

    Yes, however you'll still get duplicates with the current proposal
    for any new subscriptions that you haven't added to the subscription
    ID set, and quite frankly that just adds yet another layer of
    complexity to the server's processing of the request:

        Copy subscription ID set to local list
        Copy sequence number set to local list
        for each subscription for recipient URI
            if subscription ID in local list then
                do nothing
            else
                add subscription ID to local list
                add sequence number 0 to local list
            endif
        endfor

    I'm not sure if this level of complexity is needed or not?

    In the case of the wait-mode Get-Notifications, providing the
    recipient URI will give you all events from all matching
    subscriptions, without duplicates (unless you have to re-poll)
    If your client can sort out N subscriptions simultaneously,
    then it can probably track the duplicate events itself and
    not re-process them. Not the most efficient bandwidth-wise,
    but it does reduce the load on the server.

    ....

    This brings up another issue (maybe it has been addressed, I
    don't remember off hand) - if you do a wait-mode Get-Notifications
    with a notify-recipient-uri, and initially there are subscriptions
    for this URI, do we also return a successful-ok-no-more-events
    once all active subscriptions expire (including their events),
    or does the Get-Notifications continue indefinitely (or until
    the server decides to close the connection)???

    -- 
    ______________________________________________________________________
    Michael Sweet, Easy Software Products                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com
    



    This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 11:49:19 EDT