Difference between revisions of "Wishlist"
Line 6: | Line 6: | ||
Finish stripping out legacy GDBM/SQL modules and code. Unify database-related modules -- <code>DB</code>, <code>DBImportExport</code>, <code>CourseManagement</code> backends, etc. |
Finish stripping out legacy GDBM/SQL modules and code. Unify database-related modules -- <code>DB</code>, <code>DBImportExport</code>, <code>CourseManagement</code> backends, etc. |
||
* '''2.3.0:''' Legacy code is gone, but unification hasn't taken place yet. -- [[Main.SamHathaway|SH]] - 23 Aug 2006 |
* '''2.3.0:''' Legacy code is gone, but unification hasn't taken place yet. -- [[Main.SamHathaway|SH]] - 23 Aug 2006 |
||
− | * '''2.4.0:''' Unification is pretty much done. |
+ | * '''2.4.0:''' Unification is pretty much done. ~~ |
Improve the DB.pm API. Look into using ready-made CPAN modules to help with this, but only if they don't impose an undue burden. Put more format/value checking and defaults management into DB, so that the various modules that deal with data don't have to worry about this so much. be able to say "my @Problems = $Set->problems" and "$Set->save". |
Improve the DB.pm API. Look into using ready-made CPAN modules to help with this, but only if they don't impose an undue burden. Put more format/value checking and defaults management into DB, so that the various modules that deal with data don't have to worry about this so much. be able to say "my @Problems = $Set->problems" and "$Set->save". |
Revision as of 15:07, 20 February 2008
DATABASE
Add facility for doing automated database upgrades. This is pretty simple, and should maybe go into 2.2.x, so that we can actually make use of it in the 2.2 -> 2.3 upgrade.
- 2.3.0: Implemented in
bin/wwdb_upgrade
. -- SH - 23 Aug 2006
Finish stripping out legacy GDBM/SQL modules and code. Unify database-related modules -- DB
, DBImportExport
, CourseManagement
backends, etc.
- 2.3.0: Legacy code is gone, but unification hasn't taken place yet. -- SH - 23 Aug 2006
- 2.4.0: Unification is pretty much done. ~~
Improve the DB.pm API. Look into using ready-made CPAN modules to help with this, but only if they don't impose an undue burden. Put more format/value checking and defaults management into DB, so that the various modules that deal with data don't have to worry about this so much. be able to say "my @Problems = $Set->problems" and "$Set->save".
Allow sorting/searching/limiting to take place in the database instead of after records are returned, for efficiency.
Move some tables that are currently in the course environment into the database. For example, statuses and permission levels.
Split set/problem versioning out into separate tables instead of the ",v" method that's currently in use.
Add backends for other SQL databases. I'm particularly interested in SQLite, since people seem to have trouble with SQL database server management and SQLite doesn't require a separate server.
CONTENT GENERATORS
Expand "Classlist Editor" UI to allow for subscreens for complex operations. Some examples: confirmation of destructive operations, expanded options for importing/exporting classlist files (like assigning CSV columns to DB fields), sanity checks on student data.
Rewrite <nop>ProblemSetDetail to encompass editing set and problem data, problem previews, editing who is assigned to a set, and what versions are available (in the case of gateway tests). I envision a tabbed interface to make it easy to switch between editing various aspects of a problem set without "losing your place". (I have extensive notes on this offline.)
Integrate previewing into <nop>PGProblemEditor. Factor out the essentials of the "interactive problem processor" from Problem.pm for use here.
Rewrite/cleanup Stats, <nop>StudentProgress, Scoring.
Arrange for Problem.pm and <nop>GatewayQuiz.pm to have a common superclass where most of the functionality belongs.
SECURITY
Clean up the permissions system, so that there really is a single permission for each operation.
Audit file/directory, external command, and "eval STRING" handling.
Look into making WeBWorK work with taint checking turned on. Write "untaint" routines for various types of data.
DOCUMENTATION
Move installation/usage documentation into CVS so that it can be easily updated as features change.
Convert HTML/Wiki documentation to <nop>DocBook.
Clean up POD documentation in PG macros and libraries.
Integrate <nop>DocBook and POD documentation.
SYSTEM INTEGRATION
Apache 2/mod_perl 2 compatibility. We need to start porting this and see where the sticking points are. Maybe it will be easy. :)
- 2.3.0: Works with non-threaded MPMs. -- SH - 23 Aug 2006
Some kind of standards based installer, for example autoconf/automake or Perl Makefile.PL. This should be able to detect paths to external programs, test for Perl modules, and install things into into FHS-compliant directories. (FHS=Filesystem Hierarchy Standard) Having this will make packaging WeBWorK for various operating systems much easier.
Packaging for various package management systems. (APT, RPM, <nop>FreeBSD ports)
PG
Convert macros to use the parser wherever possible.