There are many parts of PET that needs finishing, rewriting or fine-tuning. You can help! Please take a look at the TODOs below, and volunteer if you know Perl and want to help! PET is very actively used and developed, so your efforts will not go wasted. Also, anybody helping in the development of PET will get extra support for the original developer(s).
| TODOs | There are many parts of PET that needs finishing, rewriting or fine-tuning. |
| Current TODOs | Please note : items marked bold are TODOs where you can help! |
Please note : items marked bold are TODOs where you can help! The numbers in brackets (e.g. [1]) mark the “importancy” of a given TODO. The lower the number is, the higher the importancy, 1 being the most important, 5 being the last important.
This documentation is only a draft. It should be extended, some parts rewritten. Many-many parts are missing.
1. The configuration parameters are not documented at all. They sould be. [1]
2. A more detailed installation documentation. [3]
3. Presentations given on PET (“Raising Your Own PET”) should be put online and linked here. [4]
4. A Hungarian documentation / introduction should be created. Other translations would be nice. (Note : we shall find out how to interface that with NaturalDocs.) [5]
5. A description of “how Perl actually works” should be put online. [4]
6. A FAQ should be constructed. [5]
7. We should have a newslist. [5]
8. It would be nice to have a script that converts the NaturalDocs documentation into POD. [5]
9. The documentations should be checked for grammatical errors and typo-s. [5]
10. The API should bee documented much better. [3]
11. Individual parts of PET should be documented much better so that others can extend / contribute to PET. Sessions, ActionMappers, Utils, Plugins... [2]
12. We need much more examples, especially at the MVC-style programming part. [2]
1. Some sound and sane example initscripts should be constructed. [1]
1. Until PET is not released as a CPAN module, we should create a tarball, which works “out of the box”, and which has nightly builds. [1]
2. Before creating a CPAN distribution, we should find out how to break PET into multiple packages, how to resolve dependencies and so on. [1]
3. A CPAN build system should be created. We should release PET on CPAN. [2]
1. An example configuration is needed. [1]
2. The local / global configuration handling is almost broken. It needs refractoring. [1]
3. Configuration parameters need finalizing. [1]
4. We need a sane deafult configuration put ing GCONF(?) [2]
1. The CLI mode (pet_run_cli) should be rethought and finalized. [2]
2. The pet_run_efcgi script and its module should be examined and finetuned by someone who understands Unix internals, more precisely signal handling, forking and in general process handling. [1]
3. We could (should?) have another external fastcgi process-manager which works without FCGI::ProcManager. [2]
4. It would be nice to have an Apache module which substitutes mod_rewrite, mod_proxy and mod_fastcgi with one module. I could write that in Perl, bu we need a native C module, DSO compatible -- you know the rest. [4]
5. It would be very nice if PET could be run without a webserver, by boundling a webserver with PET. There are some nice modules to create webservers on CPAN. We could than have a pet_run_standalone script, making the life of PET first-timers much simpler. [2]
6. Create a glue to SpeedyCGI. [5]
7. Create a glue to mod_perl. [5]
8. Create a glue to PHP. A very interesting task, I am not even sure it it is doable! [4]
9. Create a glue to mod_fastcgi, running in internal mode. [5]
10. The chroot option does not work. [2]
1. Test PET on verious POSIX/*NIX/*BSD/Linux platforms. Assure compatibility. [3]
2. Make PET compatible with Win32. [3]
1. Make template handling a plugin. (I am not so sure if this is a good idea...) [3]
2. We should export $PET everywhere inside PET modules. $PET should have $PET::Form, $PET::Query, and so on... [3]
3. [% DISP.Redirect(...) %] should issue a die(). The exception should be caught at the template process phase. [2]
4. Htaccess support is broken. [1]
5. A general authorization handler/structure should be thought out. [3]
6. We badly need an auto-refreshing in-memory cache to store volatile data. [1]
7. We have a “debuglevel” config parameter that we do not use. Make it so that we use it. [3]
8. We should have an internal module that makes PET to bind to a configured URL, where PET could be configured and monitored runtime. [3]
9. We need a Nagios plugin. [4]
10. Cron-emulation needs design and implementation. [3]
11. Pre-parsing should be chained. [2]
12. For the hopefully decadend, post-parsing should be allowed. [5]
1. Image manipulation. [2]
2. AJAX binding. [4]
3. FORM handling. Different approaches -- we can have as many plugins as we want. [3]
4. SQL / DBI handling works, but is very ugly. We need a nice wrapper around DBI/DBD. [3]
5. PET::Util::MySQL does not handle connection pooling properly.
6. It would be nice to have a simplified LWP-like plugin. Something easier than LWP, but more flexible than LWP::Simple. [4]
7. SVG support. [5]
1. Cookie handling needs to be revisited. [4]
2. It is tehoretically possible to do the template processing at the client side. That would speed up handling of PET pages by almost an order of magnitude in corner cases. This possibility needs some considerations. [4]
3. There is a module which mimics Template.pm, knows a little less, but is approximately twice as fast. Benchmarking is needed. [3]
4. We need tests to avoid regression bugs and to help periodic releases. [3]
5. It would be nice to have a tool that graphically analyzes the preformance.log. [5]
6. This TODO file is far from complete!