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
-----Original Message-----
From: Nagarajan [mailto:dnaga at hclt.com]
Sent: Tuesday, March 16, 1999 10:05
To: ipp
Subject: IPP> regarding the usage of limit in getjobs request
Hi ,
Can anybody explain the actual usage of the limit attribute which
is optional in get-jobs request ? In what way will it be useful to the IPP
client ?
the lines from IPP Model semantics reads as follows
"limit" (integer(1:MAX)):
The client OPTIONALLY supplies this attribute. The Printer object MUST
support this
attribute. It is an integer value that indicates a limit to the number of
Job objects returned. The
limit is a "stateless limit" in that if the value supplied by the client is
'N', then only the first 'N'
jobs are returned in the Get-Jobs Response. There is no mechanism to allow
for the next 'M' jobs
after the first 'N' jobs. If the client does not supply this attribute, the
Printer object responds with
all applicable jobs.
D.Nagarajan.
HCL Technologies India (Pvt) Ltd