IPP Mail Archive: Re: IPP> ISSUE 17 - Job Time Event attributes (AGAIN)

IPP Mail Archive: Re: IPP> ISSUE 17 - Job Time Event attributes (AGAIN)

Re: IPP> ISSUE 17 - Job Time Event attributes (AGAIN)

Michael Sweet (mike@easysw.com)
Fri, 14 May 1999 08:25:51 -0400

"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@easysw.com
Printing Software for UNIX                       http://www.easysw.com