IPP Mail Archive: Re: IPP> ippget Design Needs Work [use mul

IPP Mail Archive: Re: IPP> ippget Design Needs Work [use mul

Re: IPP> ippget Design Needs Work [use multi-part/related?]

From: Michael Sweet (mike@easysw.com)
Date: Tue Jul 24 2001 - 08:21:02 EDT

  • Next message: Hastings, Tom N: "RE: IPP> ippget Design Needs Work [use multi-part/related?]"

    "Hastings, Tom N" wrote:
    > ...
    > This will work, although it won't indicate if the subscription has run
    > out or just been cancelled,
    > TH> But won't it be harder for the Printer to be able to detect the
    > difference when performing a Get-Notifications, to detect whether the reason
    > that the Printer can't find any Subscription Objects, is because they were:
    > ...

    MS> The new status code would only be returned when there are events
    the subscription exists), but the current response contains all that are
    left and the subscription is then completed.

    To clarify: Get-Notifications will return the
    "successful-ok-subscription-expired" status for any Get-Notifications
    request when 1) the subscription still exists, and 2) the response
    contains all of the remaining events for that subscription (and no
    more events can be retrieved because the subscription has expired).

    If the client calls a second time, ignoring the new status code, then
    it will get the client-error-not-found status code, same as before.

    We just use the new status code to indicate to the client that it has
    retrieved all events for the specified subscription, and can it please
    stop bothering the server? :)

    I prefer a new status code to a "super-end-tag"; using a new tag will
    break existing implementations and will require changes to everyone's
    IPP message parsing code. The only advantage is that you can look for
    a byte that indicates the end of the notifications, but I don't think
    caching the last status code you saw at the beginning of the last
    event message is all that difficult, either...

    > ...
    > TH> I think that for the Event No Wait case, if the Printer doesn't return
    > the "notify-get-interval" at all, that is the indication for the client not
    > to ask again. Right?

    Then will the "notify-get-interval" attribute be required if the server
    wants the client to ask again? Won't that break any existing

    > ...
    > TH> This status code could be used with either the Event No Wait or Event
    > Wait case? But it may still be hard for a Printer to distinguish that the
    > Subscription Objects had expired (been canceled) from the case when the
    > client supplied either a subscription-id or a url that didn't exist which we
    > currently specify as returning the 'client-error-not-found'.

    MS> The logic would go something like this: Get-Notifications initially
    returns client-error-not-found if the subscription object cannot be
    found. If the subscription object is found, it returns successful-ok
    with each intermediate set of events and
    for the terminal events. For the wait case, if the subscription is
    cancelled while a Get-Notifications operation is active, a final part
    with the client-error-not-found status code is returned and the
    request is completed.

    > ...
    > TH> And how hard is it for the Printer to detect that case of clients
    > waiting when a Subscription object disappears? Perhaps, the implementation
    > keeps an internal list of waiting clients for each Subscription object so
    > that it can tell this case when the Subscription object disappears and
    > return the special 'successful-ok-subscription-expired' status code to each
    > waiting client.

    Well, if a client is waiting for more parts, then the server knows
    it has N clients connected to send the notifications to. If the
    subscription expires with no client connected, the server has to
    keep the expired subscription around for N seconds (the value of
    begin-to-expire-time-interval) or until a client asks for the events.
    If the client asks before the events timeout, the server sends them
    to the client with the new status code. If the client doesn't ask
    in time, it sees client-error-not-found.

    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 24 2001 - 08:23:40 EDT