One of the problems with querying for jobs with several successive
operations is that the jobs may change between requests. So that the client
might miss some jobs. Especially with an IPP object that schedules jobs out
of order, say on size or available resources.
So if the client asked for the first 20 and then asked for the next 20, but
one of the first 20 completed, a job could slip through the cracks. Any
solutions that leave context on the server between queries, such as in ISO
DPA, seemed much too complicated.
If a client can only save and display a limited number, then it could set
the limit to N and then pick out the range that it is interested in. When
the user wants to step on to the next group, the client would have to query
again, possible increasing N. However, it seems much easier for the client
to save the response in a file, if it can't hold all of the jobs. Also the
client should only request the attributes that it wants to display, rather
than requesting all attributes. That will shorten the length of the
response.
If a user wants to see more detail for a particular job, the client can then
do a specific Get-Job-Attributes for that job.
Tom
-----Original Message-----
From: Nagarajan [mailto:dnaga at hclt.com]
Sent: Wednesday, March 17, 1999 13:22
To: Hastings, Tom N; ipp
Subject: Re: IPP> regarding the usage of limit in Get-Jobs request
Hi,
Thanks for replying my query......
You wrote .........
" For example, if its UI can only display 50 jobs, it can defend itself
against a printer that would otherwise return 500 jobs, perhaps taking a
long time on
a slow dial-up line. The client can then go and ask for a larger number of
jobs in the background, while showing the user the first 50 jobs."
Here is a situation....
If the clients have some 100 jobs and limit is set to 20....and
if the client is interested in ..say jobs which are in 50th to 60th
position in
the list....and assume that client can store only 20 jobs at a time...for
display / some
processing ,He should query the printer object three times.........
To avoid this situation either a new attribute "index" can be
introduced as an operational attribute which will act as lower limit for
query and "limit +
index" will be the upper limit.....If there are less jobs than upper
limit....all the jobs
may be returned...
(or)
Instead of this if the limits can be made as a "range of integer"
type attribute it would be easy for the client to specify the range ....and
retrieve only the
required jobs rather than querying the printer object three times.
With Regards
D.Nagarajan.
-----Original Message-----
From: Hastings, Tom N <hastings at cp10.es.xerox.com>
To: Nagarajan <dnaga at hclt.com>; ipp <ipp at pwg.org>
Date: Tuesday, March 16, 1999 5:12 PM
Subject: RE: IPP> regarding the usage of limit in Get-Jobs request
How does this answer for the Implementer's Guide sound:
2.17 Why is there a "limit" attribute in the Get-Jobs operation?
When using the Get-Jobs operation a client implementer might choose to limit
the number of jobs that the client shows on the first screenful. For
example, if its UI can only display 50 jobs, it can defend itself against a
printer that would otherwise return 500 jobs, perhaps taking a long time on
a slow dial-up line. The client can then go and ask for a larger number of
jobs in the background, while showing the user the first 50 jobs. Since the
job history is returned in reverse order, namely the most recently completed
jobs are returned first, the user is most likely interested in the first
jobs that are returned. Limiting the number of jobs may be especially useful
for a client that is requesting 'completed' jobs from a printer that keeps a
long job history. Clients that don't mind sometimes getting very large
responses, can omit the "limit" attribute in their Get-Jobs requests.
Tom