From WeBWorK

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.

Server: renderd.

Client: WeBWorK::PG::Remote.

Contents 1 Request/reply formats 2 Potential improvements 2.1 PG source specification 2.2 Access control

Request/reply formats

Request format as of 10-Nov-2003:

       my $request = {
               course                 => $ce->{courseName},
               source                 => $source,
               modules_to_evaluate    => [ @modules_to_load ],
               extra_packages_to_load => [ @extra_packages_to_load ],
               envir                  => $envir,
               problem_state          => {
                       recorded_score       => $problem->status,
                       num_of_correct_ans   => $problem->num_correct,
                       num_of_incorrect_ans => $problem->num_incorrect,
               },
               options                => $translationOptions,
       };

Reply format as of 10-Nov-2003:

       return {
               translator => $translator,
               head_text  => ${ $translator->r_header },
               body_text  => ${ $translator->r_text   },
               answers    => $translator->rh_evaluated_answers,
               result     => $result,
               state      => $state,
               errors     => $translator->errors,
               warnings   => $warnings,
               flags      => $translator->rh_flags,
       };

This is exactly the structure returned by WeBWorK::PG.

Mike has written up a request format based on his WW1 daemon. See MikeRemoteRendering. We'll be merging these two formats eventually.

Potential improvements

PG source specification

Allow PG source to be specified by reference instead of being sent as part of the request. Add a source_ref variable to the request? Possible values:

• :included: - source is included, look at the source variable.
• :local:/path/to/problem/source.pg - source is stored in the server's filesystem. This would only be useful if the server has access to the course directories, like if it is running on the same machine. This one needs some thought, since we'd like to prevent arbitrary files from being used... renderd would have to make sure the path is allowed.
• Other things? See ProblemLibraryArchitecture.

Access control

We'd like to prevent students from using this as a DDoS attack, probing problems with various seeds, etc. IP-based access control is probably sufficient -- allow access only from machines running WeBWorK.

-- Main.SamHathaway - 10 Nov 2003