IPP Mail Archive: Re: IPP> MOD - The Get-Jobs operation and completed/canceled/aborted

Re: IPP> MOD - The Get-Jobs operation and completed/canceled/aborted

JK Martin (jkm@underscore.com)
Fri, 20 Jun 1997 11:04:32 -0400 (EDT)

This is the kind of request that makes some people believe IPP is
"too fat", IMHO, and that IPP tends to represent "DPA Lite".

Microsoft and others repeatedly stated that GUI application
issues such as viewing job status should be handled via standard
web page interfaces, where the designer of the web page decides
what information and options to provide the user.

Also, after reading your message, I now know why Harry Lewis is
so upset about the apparent disregard for the Job MIB and Printer
MIBs in the overall IPP universe.

If a GUI application wants a multi-programmatic way to acquire a
list of jobs, why not just use the Job MIB? If instead you want
a job listing "over the Internet", why don't you just point your
browser to the appropriate URL and click away?

...jay

----- Begin Included Message -----

Date: Thu, 19 Jun 1997 16:55:30 PDT
To: ipp@pwg.org
From: Tom Hastings <hastings@cp10.es.xerox.com>
Subject: IPP> MOD - The Get-Jobs operation and completed/canceled/aborted
jobs

Bob Herriot and I were talking about the agreement at the 6/17 PRO meeting
to remove the filter from the Get-Jobs operation. We think that the order
that jobs are returned should be specified as something like:

The order of jobs in the Get-Jobs Response SHALL be the oldest to
newest with respect to completion time (either actual or expected),
irrespective of job state.

The problem that remains, is that this means that the 'completed' jobs
come back first, which are usually the least interesting, though valuable
to obtain in some cases. A good GUI interface should scroll off most of
the completed jobs and show a few of the recently completed jobs followed
by the processing and pending jobs. However, that is a fair amount of
work.

If we leave the specification as always returning all jobs, some
providers will discover that clients aren't doing anything user-friendly
with the results when the provider keeps a lot of completed jobs around
for status or tracking. Then these providers will abandon keeping completed
jobs around, so that they don't look bad to users using clients that
don't do good things with the completed jobs that come back first.

So we propose to add a "return-completed-jobs" input parameter to Get-Jobs with
the following values:

'first' - return 'completed', 'canceled', and 'aborted' jobs in order
of actual completion followed by 'pending', 'pending-held',
'processing', and 'processing-stopped' jobs in order of expected
completion.
'last' - return 'pending', 'pending-held', 'processing', and
'processing-stopped' jobs in order of expected completion
followed by 'completed', 'canceled', and 'aborted' jobs in order
of actual completion.
'never' - do not return 'completed', 'canceled', and 'aborted' jobs at all.

The default value for this input-parameter SHALL be 'never'.

Comments?

Tom and Bob

----- End Included Message -----