The current RepRap host software is a monolithic Java program that imports STL files, lets you place the objects to be made on the table, slices and dices them and controls the machine.
In my opinion the slice and dice code should be a separate program from the machine controller. Its inputs should be the 3D model in STL format plus the filament dimensions and the output should be an XML file with extruder paths grouped into layers, outlines and infills. The machine controller then reads the XML and controls the speed, temperature, fan, nozzle wiping, cooling delays, etc, according to the selected material and the machine characteristics. A third layer of software should be the communication protocol to the slave device, e.g. SNAP or G code over serial, USB, Ethernet, etc.
I have moved a little way towards that model by making my machine accept G code from the RepRap host or Enrique's Skeinforge script. I throw away most of the G codes, looking at just enough to build be an internal representation of the extruder path. This is simply a list of layers, which are lists of threads, which are lists of points. From that information I can control my machine, make animated GIFs or preview the paths in a GUI. All of this is trivial in Python.
Here is my first cut at the preview GUI: -
The preview shown is from G code generated by the RepRap host, and here is the object it made: -
Behind is the same object made from G code generated by Skeinforge.bsh. The RepRap one has sharper corners and the infill is a bit better but the Skienforge one is faster to produce because it has sparse infill.
Here is a video of it being made: -
Here is my first attempt to make Vik Olliver's shot glass: -
When it got to the stem the fan could not get the heat away faster than it was arriving and the whole thing became a molten mass. I fixed that by slowing down the extruder to 8mm/s when the layer gets small: -
It took five hours to process with Skeinforge and an hour and a half to build. I couldn't get the RepRap host to process it.