PreviewRelease4Goals

This article has been retained as a historical document. It is not up-to-date and the formatting may be lacking. Use the information herein with caution.

Goals for Preview Release 4

Development plan

PR4 should be the last preview release. After PR4, we will freeze the feature set for the final release of WeBWorK 2.0. Any feature improvements will be put towards version 2.1. CVS will look like this:

    +-------------+ BRANCH: HEAD                 +-----------+
----| rel-2-0-pr4 |----------------- -- - -- ----| rel-2-0-1 |
    +-------------+   /       /                  +-----------+
           \         /       /
            \       /       /           +---------+
             \--------------------------| rel-2-0 |
               BRANCH: bugfixes-2-0-pr4 +---------+

WeBWorK::Request, WeBWorK::URLPath migration

• Use URLPath to get data from the URL (like courseID, setID, etc.).
• Use URLPath and systemLink() to generate URLs.
• Use $self->r to get the WeBWorK::Request object.
• Use $r->ce, $r->db, $r->authz, and $r->urlpath to get these objests.

%RED% Status: %ENDCOLOR% Finished.

Add "published" field to set/set_user

Add a field named published to both the set and set_user tables in the database. Supporting this on hash-style databases (like GDBM) requires modifying WW1Hash to add a publ key.

Will WW1 mind a new field? Will it ignore it or delete it?

%RED% Status: %ENDCOLOR% Finished.

Interface improvements

• Regularize notification of success and failure for several modules -- there are now DIV styles called ResultsWithoutError and ResultsWithError which provide light green and light red backgrounds for status messages. See usage in Assigner.pm.
• Replace ad-hoc scrolling lists with WeBWorK::HTML::ScrollingListWidgets.
• Abstract more HTML idioms into WeBWorK::HTML modules.

%RED% Status: %ENDCOLOR% Postponed until a future release.

Course file management

Types of course files

type	where	how to identify
classlists	./templates	files ending in .lst.
set definition files	./templates	files ending in .set. (do we care if they start with set?)
per set_user scoring data	./DATA	files ending in .sco. (WW names them as follows: S$setID-$PSVN.sco.)
WW1 course configuration	.	the file named webworkCourse.ph.
WW2 course configuration	.	the file named course.conf.
course information (like /etc/motd)	.	the file named course_info.txt.
login information (like /etc/issue)	.	the file named login_info.txt.
scoring data	./scoring	files ending in .csv. (does the user get to name these?)
mail merge templates	./templates/email	files ending in .msg.
PG snippets	./templates	files ending in .pg.
TeX snippets	./templates	files ending in .tex.
problems	./templates/*	files ending in .pg.
auxiliary files	./templates/*	files not ending in .pg.

Required functionality

1. Upload a file, optionally replacing an existing file
2. Download a file
3. Delete a file, with confirmation
4. Duplicate a file, specifying a new name
5. Edit a file's contents

I think the way to proceed is to make a WeBWorK::CourseData module, which would encapsulate all access to the course directory. This gives us the level of abstraction necessary to merge course data into the database in the future.

Once we have WeBWorK::CourseData, we can easily extend WeBWorK::FileXfer to achieve the functionality above.

%RED% Status: %ENDCOLOR% Added support for uploading, downloading, and deleting scoring files. (What else do we absolutely need for this release?)

Course directory management

We might also want to provide a method by which users can do normal file management of the entire course directory. This could be accomplished with an off-the-shelf tool. Requirements:

• Ability to to authentication against WeBWorK (with Authen/Authz) -- We might be able to disable the authentication/authorization code in the script and write an Apache::AuthWW module to take care of it before the script runs.
• Ability to chroot browsing into a course directory -- Could we do this with cgiwrap?

This looks promising: http://search.cpan.org/~pmc/Apache-FileManager-0.19/FileManager.pm. You can call it from within your own module as well as subclass it. Cool, eh?

%RED% Status: %ENDCOLOR% Problems here. Though it's embeddable and subclassable, there's no quick way to make FileManager preserve particular parameters in the query string, which WeBWorK needs for authentication. I think the module assumes that authentication is done with HTTP-Basic auth, cookies, or something in the URI.

This is a case where a modular authentication system would be nice, but I don't think it's a good idea for this release. Cookie-only authentication wouldn't be too hard to do. Send a cookie like we already do, but don't have hidden_authen_fields() or url_authen_args() return anything and change the verify logic to pull exclusively from the cookie. But I'm worried that there are places where the authen params are hardcoded.

Another option is to not embed FileManager at all, and instead run it on a separate location on the same server. To do this, we'd need a PerlAuthen module with hooks into course databases, and the authentication would be HTTP-Basic. This technically wouldn't be too hard, and I've been meaning to write it for a while. The downside is that it's more Apache configuration to do, and it would be hard to give it the same look and feel as the rest of WeBWorK.

A separate issue is that it only wants to manage subdirectories of the document root. This looks like an arbitrary limit which could be removed easily, but we'll see.

Course management

We should make a library for managing courses. Something like WeBWorK::Utils::CourseManagement. addcourse and some administrative CG would both make use of this library.

Functionality:

• Create a new course
  • Create the directory structure
  • If using SQL, create a new SQL database
  • Add a professor and (optionally) practice users (a class roster can be imported later)
• Rename a course (postponed because it is hard)
  • Rename the course directory
  • If using an sql-style database, rename the corresponding SQL database
  • If using a hash-style database, rename the corresponding DBM files
• Export a course database to an XML file
• Import a course database from an XML file
• Delete a course
  • Delete the course directory
  • If using SQL, drop the corresponding SQL database

%RED% Status: %ENDCOLOR% Finished.

Course database import/export

We want to be able to export data from a course database to an XML file, and import data from an XML file. We should create a module like WeBWorK::Utils::DBImportExport and implement the necessary functions to import and export a database. This could be used by the course administration module as well as a command line tool. (I'd like to repurpose wwdb, since I like the name.)

We want control over:

• import:
  • get XML as a string or read from a filehandle
  • import only certain records
  • import only record from certian tables (postponed because it is hard)
  • skip or replace conflicting records?
• export:
  • return XML or write to filehandle
  • export only certain records
  • export only records from certain tables (postponed because it is hard)

The schema could look like this:

<webwork>
 <users>
  <user>
   <user_id>sh002i</user_id>
   <first_name>Sam</first_name>
   ... other fields
  </user>
  ... other users
 </users>
 <sets>
  <set>
   <set_id>0</set_id>
   <due_date>2387429384</due_date>
   ... other fields
  </set>
  ... other sets
 </sets>
 ... and so on for set_user, problem, problem_user, password, permission
</webwork>

%RED% Status: %ENDCOLOR% Finished.

-- Main.SamHathaway - 16 Mar 2004