TODO list
---------

This is an approximate indicator for the priorities for the next few
releases. No timetable - they happen as and when I get the time and wish to
make the effort (but pay me and I'll put them in right away!)

4.2.0
-----

Double-check pqm and webpqadmin.pl behaviour for "pagecount" colourspace.
This will need some checking around the functions dealing with colour.

Re-arrange CGI scripts to be Debian-compliant on Debian systems...

4.2.1
-----

Add some way of detecting paper size, and using that to normalise billing
calculations - if this is difficult it will be bumped to a later
release. It may be possible to have different charge rates for different
paper sizes defined... e.g. A4/A3/A2 etc.

Implement some message translations. I have contacts who can at least do
French, German, Portugese, Russian, Farsi, Chinese (simplified &
traditional), Finnish, Swedish, Indonesian, Hindi, Vietnamese, Spanish and
possibly Danish. If anyone can do any other translations, that would be
great! I don't intend to internationalise printbill_configure... it's a hack
anyway, and the work/benefit ratio is too low. But if you would find it
useful, go ahead and add to the .pot file :-)

Translate debconf templates to languages other than English. More power to
Debian :-)

Further work on printbill.cups, to try to extend its functionality to match
the lprng support.

4.2.2
-----

Group quotas a la PyKota

Combine percentblack and friends into a single "coverage" binary which takes
a --colourspace option (after all, much of the code is common to both).

Try and detect request for duplex printing embedded in PS code? No idea if
this can work in a general sense... but it would be really nice if it is
possible. CUPS may be able to do this (?)

Try to clean up printbill_configure a bit... thoroughly test on RedHat and
FreeBSD.

4.3 (focus: SQL/LDAP backends)
------------------------------

Further abstraction of printbill's database usage such that it can use a
variety of back-ends - e.g. SQL, LDAP etc. The plan is to put the name of
the backend in the rc file, then use the appropriate module:

use $params{'database_backend'}

and use $params{'database_backend'} instead of Printbill::PTDB_File
throughout the code. Initially this will only support PTDB_File, but next
will be Printbill::PostgreSQL, Printbill::MySQL and Printbill::LDAP_File,
which will look up the database resources in printbillrc. printbillrc will
also specify a file which contains authentication credentials required for
read/write access (which will be set to mode 0600 or 0660).

One objective will be to maintain compatibility with PyKota, which already
uses an SQL database to store its quotas etc. Printbill will, where
possible, use equivalent parameter names, so a single database could be used
with both Printbill and PyKota.

4.3.0 will probably put in the infrastructure, 4.3.1 will start adding new
backends.

4.4 (focus: web interface improvements)
---------------------------------------

Online help for the web interface, and more comprehensively expose the
functionality of pqm. Maybe code up a "comprehensive printer management" CGI
script (this might be a job for PHP).

Use real cookies instead of dodgy server-side `cookies'? CGI::Cookie could
be useful. In case you hadn't noticed, I'm not a CGI script expert ;-)

Post-4.4
--------

Hack up some magicfilter-based filters for providing various
functionality... duplex, N-up etc.

Add support for pqm --set in web interface.

See how hard it is to integrate with lj2ps or better yet ghostPCL, for
people who absolutely insist upon having PCL drivers. Maybe this could, once
again, be done through magicfilter...

Test with Foomatic and other print filter systems...

Add support for billing fancy 7-colour printers. Ugh. Maybe there is some
way to abstact this... dealing with mono, cmy, cmyk, pagecount, 7-colour
etc. special cases is ugly at present.

Test with MOSIX/OpenMOSIX clustering, see how effective this is (on a fast
network with MFS/DFSA it *could* be good - but unknown at this time).

More fine-grained job splitting (?)

Find an RPM guru to create something equivalent to the Debconf stuff for
RedHat (is this even possible?)

Hack up a multithreaded ghostscript :-)

When everything else on this TODO list is implemented, I will port it to
Windows (or add more TODOs :-)
