On Wed, Nov 05, 2003 at 01:37:13AM +0100, Henrik Edlund wrote: > On Wed, 5 Nov 2003, Jerome Alet wrote: > JA> All points fit perfectly, with these additional restrictions : > > So you integrate with PostgreSQL? That's nice. I hope you do it in real > way and not in some MySQL-compatible crap way.
You mean do I use "advanced" features ? I don't use stored procedures, or rules (this one will come sooner than later), but I do use subqueries, transactions, and access rights, so this is probably not compatible with old versions of MySQL (I believe that newer versions supports these) > > JA> [6] : accounting is done at the beginning of each job for > JA> the previous job. This is identical to the end of > JA> the previous job if the print server can't be > JA> bypassed (if it can be bypassed no need for quotas > JA> anyway) > > If you have several printers, like 15, it can leave a huge window for > abuse. My solution limits this window by requireing extra steps to be > taken to abuse it. I don't understand why, sorry. > JA> [12] : Seems to be difficult to do correcly. > > Not really. Check the code in the appendix of my report when published. well, I believe we are waiting since july... :-> > JA> [13] : Probably more easily doable with LPRng, with > JA> CUPS I'm not sure this is doable at all > JA> without some work (I mean CUPS 1.1.x) > > LPRng does not support this today, it can only send error messages. Also > LPRng has no idea how many impressions were used. That's not what I meant. I mean an accounting application can easily do this with LPRng, because there's a notion of "before" and "after" a job. This notion doesn't really exist in CUPS to my knowledge. Once you've sent the job to the final CUPS filter, which is in fact the backend which controls the hardware (parallel port for example), you can just hope all will go well. The solution with CUPS is probably to replace the backend and call the original one, but I've not done this yet. > JA> I think you should add at least : > JA> > JA> [14] user should be able to know before printing how much > JA> print quota the future job will cost. So he can decide > JA> to not send the job to the printer finally. > JA> This IMHO interesting feature is supported by both PrintBill > JA> and PyKota. > > That is of no interest to the orderer of this system. Quota is simply > impressions, same for all printers. The cost of the job can not be > determined before the job has completed on the printer. One thing which was often requested to me and which will come in the next release, is quota on printer groups. Printer groups is different from printer classes in that often a printer class contains many printers all situated in the same location. A printer group for example contains all laser printers for your company, another one would contain all deskjets. This gives additionnal interesting possibilities over quota on single printers. Also think about user groups quotas (which works with my soltution too), though the user groups I define are orthogonal to the system groups present in /etc/group. bye Jerome Alet -- "A non-free program is a predatory social system that keeps people in a state of domination and division, and uses the spoils to dominate more." - RMS ----------------------------------------------------------------------------- YOU MUST BE A LIST MEMBER IN ORDER TO POST TO THE LPRNG MAILING LIST The address you post from MUST be your subscription address If you need help, send email to [EMAIL PROTECTED] (or lprng-requests or lprng-digest-requests) with the word 'help' in the body. For the impatient, to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED] with: | example: subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED] unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED] If you have major problems, send email to [EMAIL PROTECTED] with the word LPRNGLIST in the SUBJECT line. -----------------------------------------------------------------------------
