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: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Mon Jul 23 2001 - 20:05:25 EDT

  • Next message: Marty Joel: "IPP> ippget status codes"

    Ah, some issues:

    (1) how to indicate the last of multiple responses

    (2) how to distinguish between (a) Subscription objects lease time expiring
    versus (b) the Subscription Object being explicitly canceled by a client
    versus (c) the Subscription Object never existing in the first place (the
    client made up a bogus subscription-id or url).

    For the first issue of how to indicate the normal end of Event Wait Mode
    responses, Ira McDonald suggests that we define a new tag, that is like
    'end-of-attributes', but is a bigger end, say 'end-of-all-parts' tag. Then
    the tag can be returned on the end of the last Event Notification Attributes
    Group, no matter what the status code is, and the client can avoid another
    round trip to find out that the Subscription object(s) of interest is(are)
    gone.

    See my comments below preceded by TH>

    Tom

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Monday, July 23, 2001 14:10
    To: Hastings, Tom N
    Cc: mjoel@netreon.com; ipp@pwg.org
    Subject: Re: IPP> ippget Design Needs Work [use multi-part/related?]

    "Hastings, Tom N" wrote:
    > ...
    > 4. Which leaves how to indicate that this is really the last response,
    > i.e., that there are no more Subscription objects left that match? Marty
    > Joel suggests that there be a completely separate response part with its
    > own status code. The status should be the 'client-error-not-found' which
    > is the status returned when there are no Subscription Objects found,
    > whether this is the first Get-Notifications response or the last.

    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:

    (a) the lease on the Per-Printer Subscription expired (and was not renewed),
    or the Per-Job Subscription was canceled after the Event Lease time expired
    after the Job completed

    (b) canceled by a Cancel-Subscription operation or

    (c) the Subscription Object never existed.

    and it doesn't cover the situation if you
    do a Get-Notifications with wait=false - i.e. you are only getting a
    single part, and there are events, but how do you know if you need to
    ask again?
    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?

    How about adding a status code called
    "successful-ok-subscription-expired", which will be returned by
    Get-Notifications when the subscription has no more events and has
    expired?
    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'.

    That way if a subscription is cancelled *while* a client is waiting
    on more event messages, the client will see a different status code
    (client-error-not-found) and can display a suitable error/warning
    message, vs. seeing that a job has completed because of the
    "successful-ok-subscription-expired" status?
    TH> I do like having a different status though for these two different
    cases.
    TH> On the other hand, we have to make sure that we don't also need other
    success status codes, such as
    'successful-ok-ignored-or-substitutes-attributes'.
    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.

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



    This archive was generated by hypermail 2b29 : Mon Jul 23 2001 - 20:08:12 EDT