This diagram is a bit of a mouthful! :-) Lessons learned are:

1. Our architecture is so complex it needs layers. We used 6.

2. Layer order is crucial and philosophical. For example by putting Circuit Based above Cellular Structure, Cell can't use Messages for events. This will eventually be needed. Node can used Messages for event either, and this will probably eventually be needed. So Circuit Based needs to be at the bottom. But then again, where does the DK layer go? Such a quandry led to the monogram on Generation 2 Philosophy, which says put DK as the lowest layer.

3. There are many ways to do this. The Generation 2 Philosophy will help greatly.

4. There is no doubt that the Self Referential Tree works. The model uses parts to do everything except for the Plugpoint Structure layer.

5. The core non-parts can be just a single, which is a Node. This seems to have reduced the kernel to its barest minimum. Previously the kernel was a monolithic monster that prevented flexibility. That problem is totally gone.

6. Node needs to be carefully designed to be Infinitely Extensible. We will chat with Steve here. His slots concept may bear fruit. Also Node needs replicate() so configured nodes can have offspring with the same behavior.

7. The Message subsystem dominates the core. This was a surprise. We need to take a few more design passes on it. One possiblity is defining a MessageDefSet with DK and a Param. This would eliminate 3 interfaces and 3 classes.

8. Why so many interfaces above the Circuit Based layer? The idea is once we have Messages for part IO, you don't need any more traditional methods. But it seems methods have high value for some situations. Here we are using them to define part IO connections and circuits. But looking closely, couldn't we convert PartCommandable to Messages? What about ParamDriven, a very sensitive one? What about the rest? Hmmmmm..........

9. We probably need a MessageGroupIn abstraction. Messages replace methods. What replaces interfaces? A client needs to know what groups of Messages "in" a part supports. This could be done with a MessageGroupIn that had a name and list of MessageDefs in the group. It's possible a similar thing for out Messages will be useful.

10. We need a quick way to determine if a part supports a particular Message in. For example the Message name "SetPart" with property "Part" could replace the PartUser interface. For example the Message name "SetParam" with property "Param" could replace a portion of the ParamDriven interface. This sort of thing could eliminate all these extra interfaces, leaving only Message in and out.

11. How do we verify that a system's Message needs are met? If some are like "SetPart" and are dynamically used, there's no way to use a static Message Chain. Only static Message Chains can be verified. Hmmmm.... Perhaps Message definitions need to specify dynamic or static connections?

12. Messages are viable for layer events. They are shown by the arrows. But there may be some confusion in using them in CellMessageHandler, which needs to use a Message as an event, but also receives and sends Messages as its primary responsibility.

13. We need to have a core design spec. It would include things like "Use Datatrons exclusively for inter-part collaboration" with allowable exceptions noted. For example is setParam(Param) a violation? Should Param be a datatron?