"Hastings, Tom N" wrote:
> ...
> Alternative 1. REQUIRE the "time-at-xxx(integer)" time tick job
> attributes and RECOMMEND the "date-time-at-xxx(dateTime) date time
> job attributes.
I like this alternative best, as it means that clients can depend on
having at least one set of attributes. If the printer doesn't support
the "date-time-at-xxx" attributes and the client needs to show the
date/time information, it can fallback to using the "printer-up-time"
attribute to compute a date/time value; using the UNIX-style time
stuff the code is simply:
date-time-at-xxx = time-at-xxx - printer-up-time + time(NULL)
This won't be accurate for printers that keep jobs between power ups,
but I suspect that any printer that has onboard storage for that sort
of thing will also have a built-in RTC and be able to support the
"date-time-at-xxx" attributes anyways...
> Alternative 2. A Printer MUST support either:
>> option a) the set of 3 "time-at-xxx(integer) and
> "job-printer-up-time(integer) Job attributes
>> OR:
>> option b) the set of 3 "date-time-at-xxx(dateTime) Job
> attributes and the "printer-current-time(dateTime)" Printer
> attribute
> ...
The main weakness of this alternative is that it requires a client
to support both methods, even if it only needs the relative time
(e.g. "Job xyz is pending, queued 23 minutes ago...")
Also, computing relative time from "date-time-at-xxx" won't
necessarily be easy (there is some limited support for this with
UNIX-style time functions, but you need to use a GMT timezone to get
things right.)
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com