On Mon, 2004-06-14 at 20:48, Jerry Haltom wrote:
> > The way things are typically set up now, a job is submitted to the local
> > cupsd, which immediately forwards it on to the remote server via IPP.
> > Our D-BUS patch for cupsd has it send back the remote jobid, which
> > causes eggcups to begin polling that job on the remote printer.
> >
> > Local jobs are treated basically the same as remote jobs are.
>
> 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).
I'm not sure what you're trying to say here. Why would you have two
queues referring to the same printer?
> 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.
Right now, if a job is simply waiting in a local cupsd queue to be
forwarded remotely, we display that as "Sending".
> 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.
That's a job for a separate administrative tool.
> Users also do not recognize jobs by job ID in anyway (well, mine don't).
> They see the Job's subject tag (application specific).
Of course, we display the job name, not the job ID.
> 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.
The way we do it now is more efficient - we only poll the users' jobs,
as long as they're not complete.
> Does knowing which local job id corresponds to which remote
> job id really even matter?
As an implementation detail - yes. It lets us display it as one single
print job.
> 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).
Think of a laptop. You start a print job, and it gets put into your
local cupsd queue, to be forwarded to a remote queue. While your local
cupsd is being swapped in, your network cable gets unplugged. Your job
is now stuck locally. With our approach, to the user, this just appears
as "Sending". If we only polled the remote printer as you suggest, the
user would have no idea what happened to their job.
> The end result of all of this would only be to see the notification icon
> if he has jobs in the queues,
That would mean that if you wanted to see your job history ("which
printer did I print to again?") you'd need a separate menu entry or
something; it's simpler I think to just keep the icon around, at least
for a while.
Attachment:
signature.asc
Description: This is a digitally signed message part