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