I agree with your points. If you remember we had similar discussion as this maybe a year ago. I think the current design satisfies Till's requirements expect for the QSocketNotifier issue (I'm not going to call it a PyQt bug at this point since I still am not sure).
To summarize Till's requirements/issues:
1. Save faxes in a file. This is already the current design. Fax files are saved in ~/hpfax/. They are never removed by the software. They can be added back into a new fax by adding them as any other file. In the future, I hope to support a fax file viewer so that they may be viewed before adding. Since we do not use a standard G3 file format (the format is documented in fax/fax.py), kfaxviewer (or similar) will not work (this is also because at some point in the future, we hope to support color faxing, which uses the JPEG format and kfaxviewer only supports TIFF I believe).
2. Logging. This is possible by hpssd with 'sudo hpssd.py -gx' and the sendfax UI with 'hp-sendfax --gg'. Logging for hpfax: goes into the CUPS error log like any other CUPS backend.
3. Determine SIP/PyQt versions. The utility 'hp-check' shows this info (in the next release, 1.6.11). There is already code in the current release for this, it simply needs to be hooked up.
4. Faxes don't get "lost" if hp-sendfax not running. This is currently the design, with a caveat. Currently, faxes are pushed to hpssd and stored in memory until hp-sendfax "picks them up". A power outage or exhaustion of memory could cause a problem with this design. So, I am considering having hpssd queue up the data in file stores rather than in memory.
5. Faxes leave the CUPS queue immediately. This is the current design. The fax is pushed to hpssd as soon as the rendering step is complete. They are queued in hpssd until an appropriate hp-sendfax client pulls them.
6. hp-sendfax can be closed without faxing and the fax jobs do not get lost. As I said before, I so not agree with this as a design element, esp. in light of item 1. If the user cancels without sending the files, I assume that is the equivalent of 'lprm'. The job is lost. (However, due to item 1, it can be recovered.)
7. CUPS's filter work to get a job converted to G3 can easily be monitored by watching files appearing in the hot folder and by opening them with Konqueror (Konqueror uses KDE's fax program to display G3 files). If I were to implement the changes in item 4, this would be satisfied.
8. The data flow is much more clear to users and admins, so debugging is easier. Also maintaining it secure is probably easier then. My feeling is that the combination of logging in hpssd, hp-sendfax, CUPS output of hpfax:, and the files that are permanently stored in the user's home directory adequately address this issue. The remainder of doubt can be handled with a technical document with troubleshooting steps and data flows.
(Till, did I leave anything out?)
So, my planned steps are this point are:
1. Investigate the QSocketNotifier issue. We will continue to try to work with Riverbank for a solution.
2. If that fails, consider making the hpssd <--> hp-sendfax communication polling based. There are still two other areas (hp-toolbox and hp-fab) that are affected by this issue, but those can also be solved, I believe, by poilling. I dislike polling for the obvious performance and I/O considerations, but I think it would be workable if done correctly.
3. Implement to save to file in hpssd as outlined in item 4, above. This is probably a good idea irregardless of the QSocketNotifier issue.
Longer term, I think I might have to consider moving to PyGTK or wxPython. I would be sad to have to do this, as I really like Qt and I think overall the PyQt/SIP software is excellent. But, this is an important feature and this issue is a show stopper. Maybe the alternative is to port to PyQt4 and see if QSocketNotifier will work for me there.
Thanks for all the input and assistance,
Don
On 10/31/06, Johannes Meixner <[EMAIL PROTECTED]
> wrote:
Hello,
On Oct 30 19:22 Till Kamppeter wrote (shortened):
> When a user sends a job into the fax queue, the hpijs driver converts
> the job into fax G3 format and the hpfax CUPS backend drops the fax G3
> file in the user's hot folder (hot folder created by hpfax backend if
> needed).
No!
1.
The user's home directory is sacrosanct for any process which
does not run under the user's own ID (the backend runs as root
or as a system user like "lp").
2.
It cannot work via network.
I.e. when the user sends a fax by "printing" it from his workstation
to a remote fax/print server where HPLIP and CUPS actually run.
Even if this is not yet supported it will be supported in the future
(as far as I did understand the HPLIP authors) and then such
dirty and ugly hacks will fortunately break.
Of course there is a big difference whether a particular user
finds software which uses such evil hacks in the Internet
and installs it on his particular workstation or whether
such a kind of software is distributed by a company like HP
or distributed and installed by default by a Linux distributor.
Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: [EMAIL PROTECTED]
90409 Nuernberg, Germany WWW: http://www.suse.de/
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
HPLIP-Devel mailing list
HPLIP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hplip-devel
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ HPLIP-Devel mailing list HPLIP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hplip-devel
