This is the first "big feature". We want to transmit data other than cluster state. My thinking is we want a simple mechanism to share data. Do not try to be a database or implement leader/follow at this phase. I see those as recipes for 'later'. ' My goals for the V1 cut would be.
1) A message GossipDataMessage separate from the https://github.com/edwardcapriolo/gossip/blob/master/src/main/java/com/google/code/gossip/model/ActiveGossipMessage.java 2) Make https://github.com/edwardcapriolo/gossip/blob/master/src/main/java/com/google/code/gossip/manager/ActiveGossipThread.java extendable or duplicate it to transmit the messages above 3) A map of data keyed by node id eg sharedData : { "node1": { }, "node2:" {} } In this way there is no multi-node concurrency issues. 4) The model for the data looks like this: GossipData { String senderId; // who made this data Long dataTimestamp; // The time the data was created by the node inserting it Long expires; //When the data should be removed and no longer gossiped Object data // the actual data } 5) encoding: We do not want to force in gossip someones classpath to contain, kyro, thrift, jackson, protobuf but people will use these. I think we convert the project to multi-module and extract this the api would be something like this: GossipDataManager.gossipData( Long createdDate, Long expires, GossipDatum datum ) GoppipDatum could be extended by KyroGossipDatum, JacksonGossipDatum, etc. In the end the wire proto would be Jackson JSON, this piece would control how the GossipData.data is encoded Later thinking: 1) a shared space not keyed by node 2) encode messages like GPG emails so that all can read but it can be established is the message has been changed by someone gossiping it. 3) implement a recipe for "atomic" something 4) implement a recipe for CRDT something Should be fun!
