kugler at us.ibm.com wrote:
> ...
> I don't know what a server is in IPP. We've got Printer, Job, and
> Document. I wouldn't mind having a Server object though, along with
> a Queue object. We (IBM) have considered implementing these as
> extensions.
A Server object would be a good addition, and it would allow us to
use standard server operations instead of our current extension ops.
(CUPS-Get-Printers, CUPS-Get-Classes, etc.)
I think a Queue object will usually map directly to a printer object,
but even with CUPS queues can be "classes" that map to one or more
printer objects, so that would make sense.
We've also been toying with the idea of a "multicast" type of queue,
so you could have the same job fan out to multiple printer objects.
We're still not sure how to handle the notification requirements with
this type of setup, tho...
> ...
> > 5. How do we pass authentication information to the new
> > server?
> >
> The same way it was received by the old Printer.
However, that won't work with Digest authentication, since the
hostname, nonce, etc. will be different. Also, one would hope
that users have different passwords on each IPP server.
> ...
> I could see this argument if the Redirect-Job target were a
> different Device within a Printer. But since the target is a
> different Printer, and server is undefined, this operation seems
> poorly specified to me.
Unfortunately, printer devices don't really map to print queues,
which is what we're trying to accomodate...
I think your idea of Server and Queue objects may be what we need
to adequately define Move/Redirect-Job operations for a general
IPP specification.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com