Uploading and Storing Remixes on the Backend

After examining the current way in which remixes are saved and loaded, I have concluded that we will want to modify the process slightly but keep most of it intact.

The three main steps of the remix storing process that need to be defined are the starting point, the format in which the remix will be saved, and the end point.  I will explain these steps in the current remix storing process.

The remix storing process begins when an instance of the Precompiled Script class is created.  Prior to this point, the user has selected the start and end points for the remix using the remix UI.  The Precompiled Script constructor takes references to the selected start and end nodes, finds the common parent of those nodes, and uses a ReferencesCrawler to analyze the abstract syntax tree (AST) and generate data structures.  Significantly, the only input that is required is references to the start and end node, which offers an alternative way to store the remix while making minimal changes to the code of the current remixing process (more on this later).

The XML format that is used to save the remix to a file stores a copy of the AST, some project identification information, and additional data structures containing information needed to add the remix to another world (e.g. roles).  All of this data comes from the Precompiled Script class.  When the XML file is read back in, the data structures from the Precompiled Script are recreated, but no instance of the Precompiled Script class is created.  Instead, most of the data structures are used to create different data structures which are encapsulated in a Compiled Script.

The end result is that the Compiled Script contains the data structures needed for the AssignRolesOperation to insert the remix into another world.  While the data structures in the Compiled Script are necessary (unless we want to make major changes to all of the remix code), there is no need to write the Precompiled Script to a file before creating a Compiled Script.  The current implementation recreates the data structures of the Precompiled Script before creating a Compiled Script, so it is easy to go straight from a Precompiled Script to Compiled Script.

I recommend one of two options:

1) The simplest option is to use the current XML format to store remixes.  Since we want to store the remixes in a database on the server instead of on the local machine, we can write the XML to a socket instead of a file by simply replacing the file stream with a socket stream.  This is not a bad option because the XML format is storing entirely meaningful data.  However, since the worlds are also stored on the server, it might not be necessary for the remix storage format to store so many data structures.

2) The remix storage format can be as simple as an indentifier for the world that the remix is from and identifiers for the start node and the end node.  We can use the start and end node identifiers to obtain references to the start and end node objects in the original world.  We can then pass these start and end node objects to the Precompiled Script constructor and continue with the current process.  The only change in the process is that we would convert the Precompiled Script to the Compiled Script without first saving to disk.  This approach will avoid storing redundant information but will require us to read the entire original world into memory in order to obtain the start and end node objects.  This might require sending an entire world to a user's Looking Glass IDE just so that the remix can complete.  The current format is entirely self contained.