The author describes separating the application from the architecture, and while I've done this before in software on several levels, I never considered removing the application completely from the compiled software and driving application behavior from what the author calls "external structural and behavioral metadata". Using the same binary program to support multiple applications without recompiling a single line of code? Perhaps without recompiling on each and every application release, which makes perfect sense. However, he avoids rebuild for complex screen-level changes, too (even cosmetics). Not too shabby.

The project examples are pretty hot - I can see how he could suggest compiling software only once and doing high-speed application re-delivery with this as a foundation. We deploy software nationally for retail point-of-sale systems and are moving into wireless hand-helds, so the prospect of delivering application-level changes without new compiled binaries is quite intriguing.

His "toolkit" includes a linked-list manager (Iterator) which by the author's own confession is not new, but does provide some rather interesting twists on data organization. The linked-list as binary tree is of particular interest, since it eliminates linear searching of large data sets. The XML support is good, and I like the ability to build a very complex custom structure, reduce it to XML, then reconstruct it from XML again. This has significant implications for our XML -based applications that don't talk to each other any other way, and don't support or co-habitate with the .NET XML subsystem. I can see how using this functionality at a lower level could allow two otherwise closed systems to share common structures, or save the structure to a database as XML text for a very advanced version of behavioral persistence.

I would suggest using this structure for XML support but not for an XML foundation. I think the author *likely* would agree that available XML-support components are an adaptable technology in their own right, but would fit right into his component model like any other. Again, I like the flexibility, especially since our internet servers are all Unix and Linux portals.

I rigged up an example of his TurboCollection along with the interpreter and saved its run-time state into XML in the middle of executing an "application instruction". Not only could I persist the operational state of the application, I could retrieve it and pick up where I left off. This form of behavioral checkpointing is very hard to pull off at an application level, but the data structures make it fairly transparent. A side note to this is in managing XML-based transactions and queued states, indefinitely storing the application's state while it pends for new instructions.

However, without a really good handle on software development and a reasonably strong foundation in data structures, perhaps even compilers, the architectural strength of this model would be lost. I've got friends who build game applications using game engines with similar characteristics. For people using it to deploy applications without touching the actual software, this model could probably be further simplified and optimized.

His interpreter is also simple but intriguing, in that it can accept instructions on the fly much like the Microsoft Visual Studio .NET "command" window, yet there's no .NET IDE in sight. In the embedded "watch" window I could single-step through the "application" without the development environment. Add to this the ability to define and view "virtual" data constructs or even load and execute new instruction sets without stopping the program - and I can say the author has done his homework.

For anyone who cares, the project exercise fine print shares a little secret: that the demo software program included in the downloads is the author's full metamorphic model with "some disabilities" (although he doesn't say what the disabilities are, only that they are performance-related to inhibit production deployment). If this is true, and the metamorphic software is really this small, I'm very impressed.