| 1 |
// $Id$
|
| 2 |
|
| 3 |
This is a listing of known bugs, features that mostly work but are still
|
| 4 |
somewhat in progress, features that are being considered or planned for
|
| 5 |
implementation, and just miscellaneous far-out ideas that could, in
|
| 6 |
principle, be implemented if one had the time and inclination to do so.
|
| 7 |
|
| 8 |
(NOTE: there is no guarantee any of these items will, in fact, be
|
| 9 |
implemented, nor should any possible scheduling indications be construed as
|
| 10 |
promises under any circumstances. TANSTAAFL. If you absolutely need
|
| 11 |
something implemented right now, please contact the developers to see if
|
| 12 |
they're available for contract work, or if perhaps a modest donation could
|
| 13 |
speed things along.)
|
| 14 |
|
| 15 |
TODO: IN THE WORKS
|
| 16 |
------------------
|
| 17 |
* Finish up administration interface for pre-generating static files for all
|
| 18 |
pages on the Drupal site in one go.
|
| 19 |
* Test interaction with other modules that also make use of ob_start().
|
| 20 |
|
| 21 |
TODO: FUTURE IDEAS
|
| 22 |
------------------
|
| 23 |
* Add a node-specific cache lifetime setting.
|
| 24 |
* Add admin-visible block for updating the cached copy of the current page.
|
| 25 |
* Other web servers than Apache are not supported at the moment. This is due
|
| 26 |
to the way the cache dispatch is implemented using Apache mod_rewrite
|
| 27 |
directives in the .htaccess file. Lighttpd support would be desirable but
|
| 28 |
is not a high priority for the developer at present.
|
| 29 |
* User-specific static page cache. Could conceivably be implemented based
|
| 30 |
on the existing user-cookie mechanism, though security would be a concern.
|
| 31 |
* Don't delete the entire file system cache when Boost is disabled; just
|
| 32 |
rename the site's cache directory with the suffix `.disabled', speeding up
|
| 33 |
cache regeneration once the module is re-enabled?
|