Project Planning Feb 8th, 2018

Date

08 Feb 2018

Attendees

Goals

Status update on Rholang Interpreter
Map out objectives for the coming weeks - and how pieces come together for a release.

Discussion items

Time	Item	Who	Notes
5 min	Interpreter status	Kyle Butt, Henry Till, Former user (Deleted)	Great progress being made on normalizer. Still need to handle bindings- we can sort the receives based on the channel. If reading from different channels, can put the channels in order. Should be able to sort the pattern, each has its own free variables. Intention is to sort the for's Kent submitted a PR for the sorts - needs Kyle to take a look. Used a score tree, rightward branching tree, has the score of the term and the score of the inside of the term to the right. Using the matcher pattern that Kyle also uses in the normalizer. Henry - He coming to terms with the design of the Tuplespace. Conceptual barrier of putting out the general purpose storage library versus something that is closely coupled with the Interpreter. Tuplespace is getting tightly bound to Rholang, but it could still be useful to release on it's own. Medha states that the priority is to delivery Mercury. A separate library is a nice to have. Henry would like type signatures for consume and produce. return type is continuation, which is returned based upon a match of the tuple. Shared data types and protobufs and code sharing. Plan is to implement CORE-174 and send to Kyle for code review.
	Node Code Status	Chris Kirkwood-Watts	Doc review update (JSON API (RPC and Websocket)) What has been built so far Not precisely compatible with what Lykka wants, but that is pretty far away. Moved comms main out to Node main - realized that it was hard to build.
10 min	Last meeting rolled over items	Timm Schäuble, Henry Till, Kyle Butt	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. No multi-threaded engine. Can run many VM's - but each VM cannot run multiple threads. We will need to eventually fix this, lacks performance. How does the node come together? Primitives or Node Code that wraps it up. Notes from meeting below: Node code would start up the comms and storage and pass these to the VM? Seems reasonable? For example, upon startup, the VM was passed the location of storage, and the VM nows know about where it can be accessed. Mike thinks that Nodes should manage collections of VM's - deploying contracts, managing VM's, requesting a name to be registered. The individual VM's would then create storage objects if they need them. Use a FFI or primitives - VM would be responsible for hooking itself up to storage? Every time something goes through the tuplespace (aka a produce) - it logs whatever it gets, and pushes this out to the communications layer. Is something absorbing a log? Yes - something consumes the log and feeds it to the network and / or storage. replace table_add and table_get with a call that works with LMDB
10 min	What's Next for Node	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 VM OpCodes View VM Output Tail Logs Start and stop emitting metrics Target for the next release is March 15th. 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. VM Option: Can we write a primitive to send a message across the comms layer - and could the VM execute it - As soon as Transition is done, we could do something. Possibly done by end by March. Up next VM into the Node - write programs using opcodes that does something interesting and demonstrates the use of the comms and storage layer. Implement more Primitives - If we have primitives that can be invoked using ApplyPrim() - we can demonstrate many primitives even without boot.rbl.

Action items

From Last meeting

Henry Till : Review JSON API (RPC and Websocket) and provide feedback.
Timm Schäuble : Review JSON API (RPC and Websocket)
Timm Schäuble: Validate that Roscala is re-entrant.

New action items

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.