IPP Mail Archive: RE: IPP> Duplicate ippget events

RE: IPP> Duplicate ippget events

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Jul 27 2001 - 20:35:59 EDT

  • Next message: Hastings, Tom N: "RE: IPP> Duplicate ippget events"

    I put the following ISSUE with the IPPGET spec on the IPPFAX WG agenda for
    next Wednesday, August 1, in Toronto:

    ISSUE 07: For Event No Wait mode, should we add a way for the Notification
    Recipient to have the Printer filter out returning Event Notifications that
    the Notification Recipient has already received in order to reduce the
    duplicates (that will usually happen, else events will be lost)? Or should
    we just depend on most usage using Event Wait Mode, so that there aren't
    duplicates? It has been suggested on the mailing list that the Notification
    Recipient could supply pairs of the "notify-sequence-number" and
    "subscription-id" and the Printer would only return events with a higher
    sequence number.

    However, I realized that I made a mistake. Instead of needing pairs, we
    could just make it work when the client is already supplying the
    "subscription-id", so that he is only requesting a single Subscription
    object. So the real proposal would be to add the "notify-sequence-number"
    as a REQUIRED operation attribute for a Printer to support, but OPTIONAL for
    the Notification Recipient client to supply. Sounds really simple.

    We could even REQUIRE the client to supply the "notify-sequence-number",
    whenever it supplies the "subscription-id".

    Tom

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Friday, July 27, 2001 16:57
    To: Hastings, Tom N
    Cc: Marty Joel; ipp@pwg.org
    Subject: Re: IPP> Duplicate ippget events

    "Hastings, Tom N" wrote:
    > ...
    > However, remember this problem is only for using Get-Notifications
    > in Event No Wait mode (polling). For Event Wait mode, there aren't
    > any duplicate events returned to a Notification Recipient. If we
    > think that the majority of use will be with Event Wait Mode, then we
    > don't need to solve the problem for Event No Wait Mode.

    Even with the multipart encoding, I think there will still be a
    significant number of implementations that don't implement the
    event wait mode, and if we don't provide a way for clients to
    specify what they've already seen then the efficiency of ippget
    in this mode will be quite poor.

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



    This archive was generated by hypermail 2b29 : Fri Jul 27 2001 - 20:38:01 EDT