== Traditional Gump ==
Traditional gump has this architecture.
=== Basic Elements ===
* an object model (in java)
* an object model representation (in documentation and xml)
* a way to transform an object model expressed in xml into the java object model (in java, using DOM)
* a way to transform that java object model back into a different kind of xml (using DOM)
* a way to transform that xml into shell scripts (using XSL) that output html
There's some additional glue for doing various things, in the form of shell scripts, web server configuration, etc etc. For example, shell scripts exist for calling parts of the generated shell scripts.
=== Sample use cases and their implementation ===
==== Build all java projects known to gump against each other ===
Download the gump module, create an XML profile, set some environment variables, install dependencies, copy a whole suite of installed packages from an existing gump installation, create a crontab.
On invocation through the crontab, a script invokes a java application which creates a giant xml tree, then invokes a java applications which transforms this xml tree into giant script files, then runs these giant script files. On completion, some other script files are or can be run to do some other things (like send out failure notifications).
=== Fix a descriptor<->project build mismatch ===
After receiving a nag e-mail, click on the provided link and read a (usually very familiar-looking) build report and analyze the failure. After identifying the mismatch, locate the appropriate XML file in gump cvs, edit it by hand, run an ant script to verify syntax, commit. Wait for a day to see if things work.
On invocation of the ant script, the ant script does the equivalent of what a DTD-aware editor would do, then builds the GOM and walks it to check for circularities.
On invocation of the commit message, nothing happens, and the next batch run will hopefully yield better results.
(Scripts are available to check things directly provided you have console access to the server, but only a handful of people (approximately 4 or 5 on the planet) know how to use them and have access to them. None of them have the time needed to do this for all the other people on the planet.)
== Python Gump ==
=== First iteration ===
Basically a lot of the same behaviour as with traditional gump, but java+xsl is replaced with python, and all the shell scripts stop working. Proof of concept.
=== Second iteration ===
A wxWindows-based GUI keeps a complex and confusing (to mere mortals) but extremely powerful object model in memory. The basic workflow actions and use cases for the java-based gump are ported to this GUI one by one. Most importantly, the functionality for immediate debugging that was once available in scripts is integrated.
=== Third iteration ===
The GUI-oriented code is slowly refactored back into a commandline application. Some "serious" plumbing, like logging, is added. An effort is made to move the use of basic system utilities into pure python. Python is put in control of a lot more things, shell scripts are replaced with python scripts piece by piece. Output is XML, which is transformed into HTML, RSS, and other stuff in a distinct step.
A lot of the architectural overhaul done in the second iteration is lost in the light of getting the python version of gump feature-complete and backwards-compatible. It's pretty much batch-oriented again.
=== Fourth iteration? ===
It's time to introduce some architecture and some commmon idioms, because gump is starting to burst. A first step at responsibility-oriented system decomposition and seperation of concerns (did I mention I'm an avalon guy? :D)
Disclaimer: I'm not very familiar with the internals of what I called the third iteration above. I plan to get into them over the next few weeks, but I wanted to write these ideas down before I lose 'em.
- get rid of the batch-based system as a core idea. A batch is an ordered sequence of commands. While the challenge at one point was to get this ordering, it's gotten in the way of system growth and clarity know. Replace this batch concept with a command/action/event concept. Commands are sequential (we have an event bus here), need to be queued (real time won't work :D), and have the object tree as inputs and outputs.
- Get rid of the "giant tree transformations". It has proven to scale only with difficulty. Gump is a set of loose project definitions which are glued together into an acyclic object graph. The process of serializing and deserializing that graph is complex, and putting it at the core of the architecture makes the architecture complex and less transparant. Replace those transformations with a "end-user view of the tree" concept. Define the meaningful bits of information that a user will want grouped (into a page or feed, for example), and aggregrate those in an object set. Provide views of those sets. Strongly decouple most of the system's logic (in particular, the event bus) from the view system.
- Think hard about the best way to represent the graph. Traditional gump's navigation model was basically a flattened tree, an inverted flattened, and an alphabetical list. Python gump has a few new navigational structures as well, but we haven't drawn this or layed it out like one would do for a really complex website (again, the gump graph is extremely rich and complex, hence very difficult to navigate).
- Introduce node history as opposed to tree history. Already going in this direction (the failure/success state of a project being logged instead of the serialization of the tree output being logged), but it needs to be a core pattern in order to do all kinds of statistic cool stuff and in order to decouple.
- A question that might pop up: but who sends the commands? Right now, this is an algorithm which sorts the nodes in the tree into a flat list and calls them in order. That's how it should stay for a while, but I see oppurtunity for more advanced options (like users adding items to the queue, reordering the queue, priority scheduling, triggers, etc) which are difficult to support in the batch model.
Basically, merge some concepts from struts, cocoon, swing, svn, graph theory, and multi-tiered enterprise applications.
As for the buzzwords...let's create an action-based, data-centric, graph-based, versioning-enabled, highly componentized, extensible, continous integration system.
I have no idea how to do any of that in python, but it sounds like fun to find out......
-- g'night!
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
