Johannes, My comments are in-lined below.
Pete On 11/2/06 5:40 AM, "Johannes Meixner" <[EMAIL PROTECTED]> wrote: > > Hello, > > Pete, I kept you in Cc because I don't know if you are > subscribed to hplip-devel. > > On Oct 31 09:46 dwelch91 wrote (shortened): >> 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. > > Just an idea which requires CUPS 1.2 but which was not tested > at all by me: > > What about to hold the original fax job in the CUPS queue > until it is released by a user action (i.e. until the owner > of a fax job runs his hp-sendfax client)? > > Since CUPS 1.2 the backends can finish with various non-zero > exit codes which cause differnt actions, see > http://www.cups.org/documentation.php/man-backend.html > > Perhaps the hpfax backend could be enhanced to exit with > CUPS_BACKEND_HOLD or perhaps CUPS_BACKEND_AUTH_REQUIRED > might be even better when the backend processes a fax job > but the owner of the job does not run his hp-sendfax client. > (In this special case "authentication" means that the owner > of the fax job must run his hp-sendfax client.) > > When a user starts his hp-sendfax client, the hp-sendfax client > could check if there are holded fax jobs for the user > and release them. > > It might happen that this way a fax job is processed two times > by the filtering system (first before it gets hold and then again > after it was released) but I think this would be an acceptable > minor issue (software accounting information may be wrong). > I'll talk with Don about this and see what we come up this proposal. > >> 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'. > > From my point of view there is a difference between a [Close] button > and a [Exit], [Quit], [Cancel], or [Abort] butten. > For me [Close] only means close this window. > (E.g. compare "File->Close" and "File->Quit" in Firefox.) > I never had the idea that [Close] means that data may be lost. > And when via [Exit], [Quit], [Cancel], or [Abort] data may get lost, > then there is usually a information popup which tells the user > that data may get lost (see what OpenOffice.org does). I would agree, but we are experienced users and the less experienced users have been trained not to trust software because losing their data once is enough pain for them to fear software. That's why every OS now has a consistent window iconic functionality set, i.e. Close, Fold, Enlarge/Normalize the window. So using any button to convey this functionality breaks down consistency which relates to trust. So we need to find a solution that stays with in the consistent functionality of the users experience. > > For hp-sendfax it is a bit differnt because actually there is > no data lost but nevertheless after [Close] for the unexperienced > user (like me when I use GUIs ;-) it looks as if data was lost > (the fax jobs are no longer shown where they have been before). > > Perhaps hp-sendfax might store in ~/hpfax/ which jobs have been > actually sent successfully and which not and re-display by > default all those jobs (regardless where they come from) > which have not yet been sent successfully? > This would make hp-sendfax work like a real spooler and then > it might be even better to let an existing sophisticated > spooler do such stuff - see my idea above. > > > By the way: > It is perfectly o.k. when the hp-sendfax process which is run > by the user stores whatever stuff in the users's own directory. > > > Kind Regards > Johannes Meixner ------------------------------------------------------------------------- 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
