Johannes-
Not stupid questions at all - these are very good points. I can talk to one
of them, and I think maybe Dave will be able to talk to the others...
On 2/26/07, Johannes Meixner <[EMAIL PROTECTED]> wrote:
Hello,
perhaps it is a stupid question but I do not well understand
why HPLIP requires continuously running processes (i.e. daemons).
The underlying problem of my question is that because of the
daemons it is complicated to update HPLIP in a running system.
The correct way to update HPLIP is:
/etc/init.d/cups stop
/etc/init.d/hplip stop
replace the installed HPLIP files with the files of the new version
/etc/init.d/hplip start
/etc/init.d/cups start
It is not possible to stop and start the services in an automated
way (e.g. via RPM preinstall and postinstall scripts) because
it is not possible to stop (and re-start) the whole printing service
in an automated way when only one single printer driver package
is to be updated because all currently printing jobs would be
interrupted and re-printed from the very beginning which is
not possible in particular in the business environment.
Therefore I think about what the inevitable reason is
which requires continuously running processes
but up to now I didn't find such a reason.
My thoughts up to now:
1) Mutual exclusion:
Mutual exclusion is needed when different users or processes
try to access a device at the same time (e.g. one user prints
while a second user wants to scan while a third user queries
the device status).
I think a usual lock file which contains device status info
should be sufficient so that the other users can be informed
if and why the device is currently in use.
2) Track the device status:
Why continuously track the device status when no user or process
asks for it?
Shouldn't it be sufficient to query the device status from the
lock file (if another process is currently accessing the device)
or if no such file exists query it anew directly from the device?
HPSSD runs as a daemon so that events that occur when the toolbox or other
status tools are not running are collected and saved. Otherwise events that
occurred without the toolbox running would mysteriously disappear or not be
shown.
Also, HPSSD is used to handle fax communication for the case when the user
prints to the fax queue from am application the hp-sendfax is not yet
running.
HPSSD also caches a very slow to query value from some printers. Without
this cache, the retrieval of this value takes up to a few seconds during
each device open. Admittedly, this value could easily be cached in a file
instead.
3) Access permissions:
Daemons which run as root seem to solve any access permission
problem but actually they ignore any access permission policy.
If there were no "root"-daemons, the established access permission
policies of each Linux distribution could be used even for HPLIP.
Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
HPLIP-Devel mailing list
HPLIP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hplip-devel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
HPLIP-Devel mailing list
HPLIP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hplip-devel
