Re: GNOME Printing



On 15/06/2004 8:48 AM, Jerry Haltom wrote:

One of the problems I've noticed with Cups specifically is that it makes a
distinction at all between local and remote queues. Users do not
understand this, as there is only one actual physical printer (except in
REALLY BIG cases).
This is more a case of how the command line utilities talk to the cups server than a problem with the cups server itself. The local cups server simply proxies the requests to the remote cups server. It seems that it doesn't seem to proxy the get-jobs request though, which is why "lpq" doesn't seem to show any jobs.

On the other hand, the cupsd server makes no secret of which printers are local and which ones are remote. If I do a get-attributes request on the printer "ipp://localhost/printers/foo", it will tell you that the real printer-uri is "ipp://remoteserver/printers/foo". At this point, the client might decide to start talking to the remote server directly.

The cups proprietary cups-get-printers request also provides the URIs for the actual print queues too. This is also visible in the cups web interface, where the links point at the web interface of the remote print server when you try to get information about it.

So there is no reason why any printing related Gnome components couldn't do the same here.

Perhaps it would be appropriate for the code to pull the local printer,
and recognize that it is in fact a local queue to a remote printer, and
then pull the remote printer, and aggregate all the jobs.
What local queue?

It's important that users can see OTHER USER'S jobs as well. This is
fundamental in every other printing subsystem (Windows and Mac OS).
Administrators have the ability to see and cancel and manage other user's
jobs, etc.
The IPP get-jobs request includes a boolean "my-jobs" attribute that controls which jobs are displayed. So cups has no problems with this.

Users also do not recognize jobs by job ID in anyway (well, mine don't).
They see the Job's subject tag (application specific). So, does it matter
if you submit to local queue, poll local queue and poll remote queue for
jobs belonging to the specific user, and keep polling it, until that user
has no more jobs, at which point the notification icon is removed and
polling stops. Does knowing which local job id corresponds to which remote
job id really even matter?
First of all, there should only be one job id here (in IPP job ids are URIs, so the job id should tell you which remote print server it is queued on).

Second, provided that the application printing the job sets the job-name attribute, we should be able to provide the names of the jobs the same way they are provided on Windows. Using the "lpr" command line client, this is done with the -C, -J or -T options (it takes any of these for compatibility with other systems). If a job name isn't set, it uses the filename passed to lpr or "(stdin)" if you piped the print job to lpr.

So to get a useful view of the print spool, we'd need to make sure that applications provide a useful title when printing documents.

Pulling up a list of a user's job history should be, in the case of a pure
local printer, only polling the local printer, and in the case of a remote
printer, only polling the remote printer (after all, eventually all local
jobs will become remote jobs in this case).
You can get a list of the user's completed jobs for a particular queue quite easily. Just send a get-jobs request with "my-jobs" set to true, and "which-jobs" set to "completed".

James.

--
Email: james jamesh id au
WWW:   http://www.jamesh.id.au/





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]