Architected Futures™

Tools and strategies ... for boiling the ocean

EATS Engine

Discussion of the current generation of the EATS Engine Design.

Needs to fold into CSM System Specification.

As time proceeds, this becomes the EATS Engine Maintenance and Tuning Manual. It discusses the design philosophy of the engine and its Principles of Operation1.


Needs standard outline of template specifications applied, functional spec, ASRs, (distributed, message-based, etc) and other specs. (Just like everything else of a similar "nature.")

As of now, this needs to provide an architectural overview of the EATS v4.6.1 Java logical design framework.

For now: Go look at the pictures on the front page.

OK, maybe a little better than that. The attached "sub-pages" provide a series of "slide show" sets of graphics. I will add text as time allows, and priorities dictate.

MGP "Triage" is priority 1. (Planning note. That's probably true on all versions of the MGP, which will vary depending on resources and level interest. Triage is always #1. But if 35 people were interested (my new random variable) there is an approach and a pace. And seriously, that can be overload as a true start point. It needs to be paced. But 35 is a stretch goal. 35 casual interest, I'm doing all the load for a while longer, which is it's own kind of fun. 35 (or less) who represent some form of industrial capability forming, I'm doing all knowledge dissemination and no development for a while. I'm training trainers. I need 1 person for engine development. Lower interest numbers, it's somewhere in between. Identical to all other development tasks.)

Actual creation of a working engine involves getting "that" (engine) code finished. (v4.6 is available as a "running" last reference point, and useable tool for knowledge maintenance, if used with care by people who know what they are doing, and capable of self-support with complex technology.) i.e., not for full "public" consumption.

The 4.6.1 engine is set up for supporting bootstrapping of the rest of the "application" code as services, etc. It should be rolling code development again after that. [Note: Migration of all code to GitHub is also a task, migrating Maven to Hudson or whatever, etc. are also tasks. I use Eclipse and Maven on primarily Java for the engine. It's not posted on GitHub because it's been easier that way, all my life as a coder, to use my scheme when I work by myself, and a "share" scheme when I work with others on a team. But the code is set up for migration. It's organized. More or less. :) ]


  • 1. A fantastic term I learned working with early versions of the IBM S/360 in its various early incantations from DOS, OS, MFT, VM and so on. My "experience model" for generational operating system development. Is Linux "flat?" or does it have a "Vision" target and strategy path? Does that exist in the "open world" or do you need some "closed, proprietary, competitive incentive to induce that behavior? That would be a good thing to know in the design and development of our "Vision World" model so that we can appropriate do the economic factors.{Would have been good to be able to automatically xref that thought and catalog it as a TBD.}

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.