Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  •  End meeting discussion (anything else that comes up to be discussed)
    • dependency Dependency flags
    • Discussion: Guidelines for re-implementing state machines
      1.  No "Sent" states: Do not use <something>Sent  states which serve as "marker" that some message has been sent to a counterparty.
      2. Various final states: Different variants of final state should be expressed by different rust state types - eg. Success  / Fail  /  Declined  
      3. Received aries messages change state:Message from a counterparty always changes state - even if it's just ack . Finished state and "AlmostFinishedButWaitingForAck" in some protocol should be 2 different states.
      4. Intermediate states: Use intermediate states to enable separation of response processing and reply construction - for example PresentationPrepared  in ProofProver SM, PresentationRequestSet in ProofVerifier SM
        • The fact that the our "to be sent" message has been built/prepared/set (we should maybe unify the terminology there as well) means that we are expecting response (as per point 1. we do not track on state machine level whether that message has been sent, it's aries-vcx user's resposibility to deliver the message)
      5. Linearization of transitions: - each state machine transition method should either fail, or succeed and switch state deterministically.

...