Refactoring the Product Factory

Yesterday, I talked about the goals of the product factory, and made a few recommedations for how to use the CMOP product factory -- that is, what kind of products we should add to our repetoire.

Today, I want to set a roadmap for refactoring the factory itself -- What changes do we need to make to the design of the Factory based on feedback?

Observations about the Factory

• The database-powered AJAX web interace feature turns out to be very useful in other contexts besides the Factory. Currently, it cannot be used in these other contexts.
• The Factory was effective in eliminating all the boilerplate code, cron jobs, directory dependencies, and file manipulation tasks associated with the existing data visualization scripts.
• A sub-goal of the effort was to use purely declarative product specifications, which led to a simple XML dialect. However, a significant portion of the content of these XML specifications is executable Python code (the "PlotWith" tag), which isn't declarative at all.
• The use of XML was not a factor in the success of the Factory as an abstraction.
• In fact, none of the stated goals require the use of XML when authoring products.
• Further, the use of XML complicates debugging, and, worse, makes it difficult to understand how the factory really works.
• Finally, an independent goal has emerged: proliferate Python here at CMOP. So having people write Python code in a typical manner is a Good Thing.

Recommendations

1. Separate the UI-generation service from the Product Factory,allowing it to be called from anywhere.
2. Treat product specifications as programs, not declarative "recipes", at least for now. More concretely: Write all product specifications as Python classes rather than as XML documents.
3. Get rid of the XML parsing and database storage of products. "Code as data" is a good idea, but we don't have the code fully understood yet.

I'll get started on this after the November Cruise.