WeBWorK as a web service

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.

(There is a webservice and some of these ideas have been accomplished Other ideas have evolved. Use with caution.)

One idea for the future is to rewrite the core functionality of WeBWorK as a web service of some kind. At the highest level, the server side would be trusted, and the client side could be untrusted. That is, a student should be able to interact with the web service directly without being able to do anything malicious. So here's how it would look:

WeBWorK Server	WeBWorK Client
database authentication authorization control ability to view data (i.e. correct answers, lists of users, user details, etc.) control ability to submit data (i.e. send problem attempts, modify user data, edit sets, etc.) problem rendering	user interface viewing and editing of webwork objects (courses, sets, users, etc.) writing and testing problems various "interactive" problem modes (normal problem mode, quiz mode, etc.) offline storage of objects

Examples of clients include:

• A web-based "student" interface (written in Perl) that supports
  • navigating sets and problems
  • interactive problem mode
  • retrieval of hardcopy
  • viewing of status information (scores on problems and sets, other stuff?)
  • modifying a limited set of user options (email, password)
  • sending feedback
• A Perl/Tk (or Java or whatever) client for professors to use for
  • modifying the user list
  • creating, importing, and editing problems
  • assembling problems into sets
  • assigning sets to users
  • modifying user-specific set and problem data
• A moodle module (written in PHP) that supports
  • retrieving rendered problems
  • sending user responses
  • displaying feedback about attempts and correctness

The main motivations for this are:

To provide a more flexible user interface for professors. HTML forms are by no means an ideal medium for interacting with an externally-constrained replation database. A robust GUI toolkit is much better suited to the job.

To make use of the <nop>WeBWorK core more flexible. Integration with moodle, WebCT, and other systems will be much easier if the core of WeBWorK is completely abstracted from the context in which it is being used.

Another view of the system:

                        +-----------+
                        | Rendering |
                        |  Service  |===\
                        +-----------+    \
                          |               \
                          |   +---------+  \
                          |   | Problem |   \
                          |   | Library |    \
                          |   | Service |==\  \
    +----------+          |   +---------+   \  \  +-----------+
    |          |          |      |           \  \=| GUI-based |
    | Database |          |      |            \===| Professor |
    |          |===\    +-----------+      /======|  Client   |
    +----------+    \===|           |=====/       +-----------+
                        |  WeBWorK  |
+----------------+      |  Server   |      +-----------+
| Authentication |======|           |======| Web-based |
|    Sources     |      +-----------+      |  Student  |
+----------------+                         |  Client   |
                                           +-----------+

-- Main.SamHathaway - 07 Dec 2003