Re: GNOME Printing

[James Henstridge <james jamesh id au>]

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/