Update after meetings with folks on Storage and Tuplespace
How does storage interact with multple VM's / Nodes in the future, 1:1 or 1: Many
Need to dedicate 1 thread / queue (containing context) is the way to go. Timm is not sure that this would work. Synchronization would happen via com events.
The transition function is completely re-entrant - that is Mike's understanding. If it isn't we need to figure out what it is. - Timm Schäuble Has an action item for this.
Decision is not to implement multi-threading. Problem is how to sort out merge order for these threads.
10 min
Node.Void Release
Everyone
What comes after Node.Hello: Node API for Communications
Node.Void→ Node Application Layer & Start of Node API→ Mid March (Chris is out next week)
Start and Stop the VM
Start and Stop comms library
Run interpreter? Depends on what can be delivered
Tail Logs - we are not going to offer logs - please confirm.
Start and stop emitting metrics
Target for the next release is March 15th. Cut packages on March 12th
Interpreter Option
Kyle believes he can cut an SDK - we won't have a process matcher in that time. So some things will be possible in this SDK, others won't.
Goal is to offer the same functionality as the SDK 0.1 release. He doesn't want to release if the interpreter is a step backwards from the SDK 0.1
Action items
From Last meeting
Medha Parlikar (Unlicensed): Future feature to support multiple cores - Post Mercury (assumption is that there will be a single storage tier for N VM's / Interpreters)
Medha Parlikar (Unlicensed): Schedule a meeting with Chris, Henry and or Nash to discuss how the pieces come together in the node. Create a spec document that will likely feed requirements into the interpreter.