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