[cups.general] Passing extra information from environmenttobackend?

Johannes Meixner jsmeix at suse.de
Fri Oct 19 06:38:00 PDT 2007


Hello,

On Oct 19 05:29 Erik Forsberg wrote (shortened):

> > As far as I understand it this cannot work because
> > he is looking for a way that the same user is logged in
> > several times at the same time and therefore any central
> > place where an option setting is stored cannot work
> > to distingush the sessions of this one user.
> 
> Correct.
> 
> > I.e. I wonder what the final purpose is why to distinguish
> > between the sessions when all is done by the same user?
> 
> It's a thin client environment. Imagine a user that logs in from home,
> running program A on a central server. He then takes his bike to work,
> and runs program B, also on the server, but in a different session.

In this particular example the same user is not logged in
several times at the same time and in this case it would work
to do during login something like

lpoptions -p thinlocal -o sessionID=<current session ID>

so that there is in his ~/.cups/lpoptions

Dest thinlocal sessionID=current-session-ID

so that all subsequent print jobs are submitted with this setting.


> It should not matter if the user is logged in from several physical
> locations - printing to "thinlocal" (which is what we normally call the
> queue, it's run by a backend we've written) should always make the
> printjob appear at the terminal where the user is located when
> submitting the print job. 

Perhaps it could be made sufficient even if the same user logs in
several times at the same time because the lpoptions command
would always set the latest session-ID so that printouts
always apperars at the location where the last login happened.

If the lpoptions command could also be called whenever the
user re-activates an already running session at a different
location (e.g. by unlocking the session) or whatever he might
have to do when he re-activates an already running session
it should be sufficient to make the printjob appear at the
terminal where the user is currently located.

The precondition is that for each user there is only one
real person so that it cannot happen that two persons
at different locations are logged in as the same user
at the same time.

Of course I didn't try out anything like this.
I only post some ideas.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex





More information about the cups mailing list