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@hclt.com]
Sent: Tuesday, March 16, 1999 10:05
To: ipp
Subject: IPP> regarding the usage of limit in getjobs request
Hi ,
=A0=A0=A0=A0=A0=A0=A0 Can anybody explain the actual usage of the=A0 =
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)):=20
The client OPTIONALLY supplies this attribute. The Printer object MUST
support this=20
attribute. It is an integer value that indicates a limit to the number =
of
Job objects returned. The=20
limit is a "stateless limit" in that if the value supplied by the =
client is
'N', then only the first 'N'=20
jobs are returned in the Get-Jobs Response. There is no mechanism to =
allow
for the next 'M' jobs=20
after the first 'N' jobs. If the client does not supply this attribute, =
the
Printer object responds with=20
all applicable jobs.=20
=A0
D.Nagarajan.
HCL Technologies India (Pvt) Ltd
=A0
=A0
=A0