So a lot has been done to the server side of the module over break, and a lot remains to be done.

Some highlights of work that has been completed:

- Implemented commands so that certain tasks can be accomplished by the server such as compiling and testing source files.

- Finished implemented an ant command that will be used to build code.

- Started implementing a junit command, its accompanying testing suite, and its client side display. This is coming along nicely, the command won’t be finished until we finalize the parameters for the testing suite. Once that happens it will quickly progress.

 

What remains to be done generally relates to the commands/testing suites as well. Originally I wanted to continue to use the database for storing the results of tests and the commands themselves. However each time I look at how that can be accomplished I realize its a horrible idea. For example to test a submission and restore the results we are going to need some way of linking the submission to the test results. However since our testing suites run as a separate process this means passing in the submission id as a parameter in some input file, and what if the tests need to be compiled server side as well do we have a separate section of code strictly for commands that operate on files that are not part of a submission? What if we want to add some extension in the future?

This problem along with the fact that you use a database for storing large amounts of data that can quickly be searched, aggregated and returned isn’t what we really need for this portion of the system. This has lead me to the conclusion that a file based solution is a much better route to go. Since the commands are given a working directory as part of their parameter (for relative path names) it will require no real modification to the existing command code and allow for extensions in the future.

 

Another possible benefit of this is that if a user’s client doesn’t have the proper module installed to view the results of some command then if the file is text based it can  easily be opened and read.

Today we did accomplished a lot. We started first by talking about current problems and what we are going to need to start look at now that we have somewhat developed our server and testing models. During these discussions many things were developed further for our prototype system. Of these the ones that effect my portion of the system (compiling, testing, reporting results) are the file structure of the system, and what information constitutes a submission, user, and assignment.

The File Structure of the submission system was finalized today so we can start implementing features for transferring files from the users to the system. We initially started with two different designs that offered benefits when displaying the directory structure to the user, for example a professor or teacher assistant would be interested in having the students be grouped by course offering while a student might want the directories to be based around their courses.

 

Design A

 

As you can see in Design A there are two main sub-directories, Courses and Course Offerings, this structure was designed with the teacher assistants and professors in mind where the students are grouped under the courses they are currently taking. This layout allows professors and teacher assistants of the course to quickly access each student within the course while if a student saw this layout they’d have to open their user folder in each course in order to get to their assignments and would quickly find this tedious.

 

Design B

 

In figure B the system is more centered around the individual users and what courses that are participating in. In this design you’d run into similar problems as in figure A only now it would be on the professor and teacher assistant having to go to each student open their directories and find the course they want for each student.

While each of these designs have similar problems vs benefits what ultimately tipped the balance in favor of design B was the fact that the number of students will be far higher than the number of professors and Teacher assistants and cleaning up the directories of old users will be accomplished with greater ease with Design B than Design A. After all in design A we’ll have to go into each course offering the student was involved with and delete the students directory there as opposed just deleting the entire student directory and hitting all the course offerings at once.

Users, Assignments, and Submissions.

The changes to these models were just clarifying what data should be included in each. For example we removed the directory field for users and Assignments as they are computable given other pieces of information. For example a user’s directory can be computed by concatnating the wpi_submission_system directory with ‘Users/’ and ‘Username+userID+”/”‘. So those fields have been removed from the model of a user and assignment.

Where to go from here?

At this point we are trying to merge Richard’s Hazelcast/cajo with Chance’s database and my junit prototypes into a somewhat cohesive system as a basis for starting the rest of our project. At the same time I’m going to be looking into authorization libraries, and sandboxes for running code with restrictions on what can be accessed such as directories and other system resources.