Design Review

[dmaretskyi]

Messages

Class diagram

[richburdon]

Tracing async event flows.

[richburdon]

From a discussion between Rich/Thomas

Goal

• [ ] Unify stream processing (currently HALO and ECHO both have open feeds.)
• [ ] Handle all HALO feed processing via models (PartyProcessor becomes a Model).
• [ ] Handle all outbound message writing via models (e.g., GreetingResponder, DeviceManager)

Implementation

Simplified form of sorting K sorted arrays.

• Instead of the current FeedStore stream (where we don't know in which order the feeds will be read), FeedStore should maintain a cursor for each feed, and is passed an evaluation function that determines if the consumer is willing to read the current message from that feed; if not, FeedStore moves onto the next feed (round robin).
• PartyProcessor implements an evaluation function will not read messages from any feed until it has read the initial genesis message.
• Messages are demuxed by the PartyProcessor to the associated Model (e.g., PartyModel, ItemModel), which is identified by the message envelope.
• The consumer may then continue to read from the feed containing the genesis message or "yield" to other feeds (e.g., when encountering an admit message).
• This ensures that we don't read messages from feeds until they have been validated as having joined the party.

class StreamEvaluator {
  processMessage(feedKey, message) {
    // Check if feedKey has been admitted to an existing party.
    const party = getParty(feedKey);

    // If not, check if this is a genesis message and if so, create the Party (which then admits this feedKey).
    if (!party) {
      return processGenesis(feedKey, message);
    }

    if (isPartyMessage(message)) {
      return party.processMessage(feedKey, message);
    }

    // Get existing item.
    // NOTE: could delegate following logic to party-specific ItemStreamEvaluator (Index?)
    const { itemKey } = message;
    const model = getModel(itemKey);
    if (!model) {
      // Create item if valid, otherwise skip.
      return processItemGenesis(feedKey, message);
    }

    return model.processMessage(feedKey, message);
  }
}

Notes

• We might know ahead of time only to open feeds that correlate to specified parties. Or to ignore messages from feeds from specific parties.
• We might only process Item system information (to build the item index) and delegate/queue model-specific messages.
• Generically, the FeedStore streamer must halt (until another feed is opened) if the consumer refuses to read from any of the current feeds (e.g., is it possible that a feed has been replicated, but the admit message is on another feed that has not yet been replicated?)

Short-term clean-ups to consider

• [ ] Strict event hierarchy: PartyManager > Party > PartyInfo > PartyMemberInfo
• [ ] Rename credentials.Party to PartyState (party-state)
• [ ] Rename: PartyMemberInfo => PartyMember, PartyInfo => Party
• [ ] Consider why we have deeply nested access this._partyManager.identityManager.deviceManager.keyChain (with respect to encapsulation).

[dmaretskyi]

UML diagram sources: https://github.com/dxos/halo/tree/master/packages/party-manager/docs

[dmaretskyi]

[richburdon]