I have some concerns regarding the use of "printer up time" as the value for
the job "time-at-xxx" attributes. While this simplifies things for small
printers without a clock, it complicates matters for larger systems that do
have a clock.
In the first place, the server must generate negative numbers for historical
jobs that were created or completed before the last power up. The Model and
Semantics spec states that the values must be in the range (0:MAX), so
presumably, this excludes negative numbers.
The second problem is that a client that periodically polls a jobs
attributes will display incorrect times if the printer is restarted in the
meantime. The client would be obliged to query the "printer-up-time"
attribute each time.
The third problem is high-end printing presses are really a collection of
print-units, RIP processors and sundry computers, so they do not have a
unique "printer up time". A press could continue to accept new jobs and RIP
them even though the inky bit was switched off. Such a system could not use
the print unit as a source of printer-up-time, since that would imply that
all jobs created while the print unit is off would have the same
time-at-creation attribute. The system would have to invent a virtual
printer-up-time, perhaps the number of seconds since jan-1-1980.
Would it not be simpler to just use a dateTime value for the "time-at-xxx"
attributes? A simple printer without a clock could then either ignore these
attributes altogether, or return its up time based to 00:00 0/0/0000. If
the printer does not have a clock, it will not be able to return the
printer-current-time attribute either, so the client cannot do very much
with the "time-at-xxx" attributes
Regards,
Anthony Porter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Anthony Porter.vcf
Type: application/octet-stream
Size: 723 bytes
Desc: not available
Url : http://www.pwg.org/archives/ipp/attachments/19990323/c20934e7/AnthonyPorter-0001.obj