Difference between revisions of "Wishlist"

From WeBWorK_wiki
Jump to navigation Jump to search
Line 8: Line 8:
 
* '''2.4.0:''' Unification is pretty much done. [[User:Sam|Sam]]
  
* '''2.4.0:''' Unification is pretty much done. [[User:Sam|Sam]]
   
−
* 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".
−
+
−
* Allow sorting/searching/limiting to take place in the database instead of after records are returned, for efficiency.
 +
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.
 +
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.
 +
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.
 +
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
  
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.
 +
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.)
 +
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.
 +
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.
 +
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.
 +
Arrange for Problem.pm and <nop>GatewayQuiz.pm to have a common superclass where most of the functionality belongs.
   
 
SECURITY
  
SECURITY
   
−
* Clean up the permissions system, so that there really is a single permission for each operation.
 +
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.
 +
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.
 +
Look into making WeBWorK work with taint checking turned on. Write "untaint" routines for various types of data.
   
 
DOCUMENTATION
  
DOCUMENTATION
   
−
* Move installation/usage documentation into CVS so that it can be easily updated as features change.
 +
Move installation/usage documentation into CVS so that it can be easily updated as features change.
−
+
−
* Convert HTML/Wiki documentation to <nop>DocBook.
 +
Convert HTML/Wiki documentation to <nop>DocBook.
−
+
−
* Clean up POD documentation in PG macros and libraries.
 +
Clean up POD documentation in PG macros and libraries.
−
+
−
* Integrate <nop>DocBook and POD documentation.
 +
Integrate <nop>DocBook and POD documentation.
  +
  +
CYSTEM 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. -- [[Main.SamHathaway|SH]] - 23 Aug 2006
   
−
SYSTEM INTEGRATION
  
  +
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.
   
−
* Apache 2/mod_perl 2 compatibility. We need to start porting this and see where the sticking points are. Maybe it will be easy. :)
  
  +
Packaging for various package management systems. (APT, RPM, <nop>FreeBSD ports)
−
** %Y% '''2.3.0:''' Works with non-threaded MPMs. -- [[Main.SamHathaway|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
  
PG
   
−
* Convert macros to use the parser wherever possible.
 +
Convert macros to use the parser wherever possible.
   
 
[[Category:Developers]]
  
[[Category:Developers]]

Revision as of 14:06, 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. Sam

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.

CYSTEM 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.

Retrieved from "https://webwork.maa.org/mediawiki_new/index.php?title=Wishlist&oldid=2369"