Refactoring Complete. Preparing to Upload to the Server.

I have finished refactoring the remix process.  The ActionScriptFactory class creates and returns an ActionScript in its createActionScript static method.  The ActionScript class encapsulates all of the data previously split between UserFunctionalityScript, PrecompiledScript, and CompiledScript.  When ActionScriptFactory creates an ActionScript it performs the entire script creation process.  There is no longer a need to first save the script to a file and read it back in. 

I also refactored ScriptFileUtilities so it can write and read an ActionScript from a file, which will be useful if we decide to store ActionScripts on the server.  Rather than writing out a PrecompiledScript and reading back in a CompiledScript, ScriptFileUtilities now writes and reads an ActionScript so the process is symmetric.  Previously, encoding a script occurred in ScriptFileUtilities while decoding a script occurred in UserFunctionalityScript.  I made the code symmetrical by placing both the encoding and decoding code in ScriptFileUtilities.

While I was making these changes, I also refactored the script code to break apart some large conglomerate methods into multiple smaller methods and to combine methods that required the same setup steps.  I also removed variables, nested classes, and methods that are no longer being used.

I have merged recent changes into my branch and pushed to the server.  Now I am considering the options for what we store on the server to represent a remix.  The simplest option is to just store the ActionScript on the server.  The ActionScript can already be written to an XML zipped file and read back in using ScriptFileUtilities.  This is the option we will probably go with.

An alternative option is to store the minimum amount of data necessary to create an ActionScript in the future.  The remix process requires an ActionScript, so without substantial changes to the entire process, we will need to generate an ActionScript.  If we store the inputs to the ActionScriptFactory's createActionScript method and store the source world's .lgp file, then we could have the user rerun the world to regenerate the EventNodes and use the other data we stored along with the EventNode AST to create an ActionScript.

The alternative approach would require us to store the world ID (communityProjectID) and the UUID of the start and end EventNodes for the remix.  This is the easy part.  The challenge is that we need the start and end times to exclude unexecuted loop nodes and to pause the program at the right time for acquiring resources and transformations.  While we could save the start and end times, they will vary accross each execution of a world and can vary greatly if the computer that the source world was created on is much faster or slower than the computer of the remixer.  An alternative would be to provide each EventNode an ordinal number based on the order in which it executed.  This can be used as a sort of relative time.  While it is possible to exclude unexecuted EventNodes this way, I am not sure if it is possible to pause the program at the right time this way.  For this to have a chance to work, the EventNodes would have to be executed in the same order every time a world is run.

I am leaning toward just using ActionScripts to store remixes on the server.