Review scope

Perform an initial vertical prototype across identity management, governance/policy enforcement and messaging. http://www.oceanobservatories.org/spaces/display/CIDev/Capability+Container+Prototype Review the examples in the source code of a specific version of Magnet.

Does the summary material clearly explain the work done? Is there enough context to understand the work done?

The summary page does a good job of describing the work done, and just as helpful is the page linked from the summary page called OOI Interaction Levels here: http://www.oceanobservatories.org/spaces/display/CIDev/OOI+Interaction+Levels, which gives a step-by-step diagram enhanced progression of the Components of the Capability Container.

The Capability Container Prototype summary page describes, (in the understanding I gained from it), these core abstraction levels of the Capability Container:

• Application Level: Where the Application, implemented as a Twisted Services, runs. The Capability Container is like a "Virtual Machine" for the Applications (similar to the Erlang or Java Virtual Machines).
• Integration Level: Using Twisted core features along with the Twisted AMQP protocol implementation, this level provides an abstraction to using AMQP. This level is usually known as the "Magnet" library. 
• Messaging Level: The AMQP protocol, using the RabbitMQ implementation.

How does this work relate to your work and your subsystem? What ideas or tools can you apply to your work?

This work relates to the work that I have done with the CEI in that a main strategy of the OOI is to have Agents (some to-be determined combination of Capability Container+Magent) to be the only service that one "interacts" with when interacting (command and control) with Virtual Machines in a cluster, to all running in the Cloud.

What issues in the content (Word, Jira, code) should be addressed, either now or sometime?

Currently, there is not a great deal of new code to test and run because this subsystem Iteration's work was more focused on mapping out and understanding the architectural components.

What interesting insights, suggestions, or thoughts can you offer for the developer to consider?

I'd suggest/agree that this work should continue to put effort in identifying what components that are desired in the Capability Container already exist in the Twisted Framework, as well in other Language/Frameworks/VMs such as: Erlang OTP, the Erlang Virtual Machine, the Java Virtual Machine, etc.