Plugin system

I'm rather surprised that nobody thought of this before (or I just couldn't find it), but why not strip down the program to bare minimum and have it run off a plugin system. greenarrow is working on using it the reprap system to make circuit boards, I know I will need that too, but I will also use it for additive fabbing like it's meant to be used as well as subtractive fabbing like a regular CNC,not to mention using different heads for each type, (drills, lasers, pens, knives, extruders for plastic, metal etc.).
Since everyone is going to use it for different things, it would be a lot easier to use a plugin system. This way the program wouldn't have to be rewritten for each thing and we can all share the code and not have to rewrite it ourselves for just what we need. In effect it would be running like maya and each thing it would do would consist of nodes. Many of the modes could use the same settings too (z axis speed and steps, size, speed, etc) and then in the options for the plugin loaded just tweek what needs to be done like if making a PCB, there would be no warm-up time and the nozzle wouldn't have to be cleaned, etc.
Let me know if anyone has started working on this kind of thing.
Dylan

This is what software engineers might describe as 'non trivial'. Setting out from the start to use this sort of modular design is tricky, as I suspect that not everything the software will eventually need to do is currently known.

More importantly, the benefits of such a design probably wouldn't be realised any time soon, given that most of the sorts of things you mentioned simply aren't being done yet. The host software is already extensible (someone made a dummy printer class that generated gcode, for example), and this should do for now.

The software is also in a state of flux, not entirely surprising givien the status of the project. In the longer term, who knows? I'd wait until the first proper release of the fabricator, and see how things stand then.

My program currently supports plotting gerber and dxf files (though neither completely), both modules though not yet loaded as plugins are structured in an identical way that will very easily allow them to be loaded automatically from a plugins folder.I intend to write a gcode backend so that people have a choice of printing directly to the reprap or saving gcode. The program is primarily intended for 2D plotting purposes (as the preview is 2D etc) but could be easily extended to any other 2d processes.

While my software skillz are confined to BASIC on the PDP-11 and therefor of little practical use I would like to weigh in on these matters as a semi-informed user.
It seems to me that the pluggin model is probably a good one in the long run, especially if it can be paired with electro/mechanical modularity of the machines. The more the "genetics " of RepRap are snap-in-snap-out the faster it's evolution will run.
That said at this stage of the development I can see where it would be difficult to create a pluggin based program because (a) we don't really know what the key variables are (what modules we need), and (2) we don't have a firm grasp on the relationships of the functions involved (what kind of framework we need). It is always easier to build monolithic code (unless the project is too large for one persons' brain to get around), and troubleshooting is easier when you don't have to worry about errors in the message passing system.
If everyone involved does their best to write good, clean, well structured code with lots of comments I don't imagine it will be too hard to convert the software to a modular format between the 2.0 and 3.0 releases