In the current API, a round defines a fn possible_next_rounds(&self) -> BTreeSet<RoundId> method, which returns an empty set if there are no possible next rounds. This is a sufficient condition to tell that this round produces a result, but not a necessary one - in some protocols we may either produce a result or enter an error round, in which case the returned set won't be empty.
This is important for the chain combinator from #60, because the empty possible_next_rounds() is how it determines when the first protocol ends. We need to know this to amend possible_next_rounds() to return the first round of the second protocol, so that caching messages in a Session works correctly.
So, the problem is: how do we signal that the round produces a result, in the least intrusive way? Should we add another method to Round, may_produce_result(), with a blanket implementation (returning self.possible_next_rounds().is_empty())? Or is there some way that will better guarantee that users don't forget to implement it if their protocol behaves differently?
In the current API, a round defines a
fn possible_next_rounds(&self) -> BTreeSet<RoundId>method, which returns an empty set if there are no possible next rounds. This is a sufficient condition to tell that this round produces a result, but not a necessary one - in some protocols we may either produce a result or enter an error round, in which case the returned set won't be empty.This is important for the
chaincombinator from #60, because the emptypossible_next_rounds()is how it determines when the first protocol ends. We need to know this to amendpossible_next_rounds()to return the first round of the second protocol, so that caching messages in aSessionworks correctly.So, the problem is: how do we signal that the round produces a result, in the least intrusive way? Should we add another method to
Round,may_produce_result(), with a blanket implementation (returningself.possible_next_rounds().is_empty())? Or is there some way that will better guarantee that users don't forget to implement it if their protocol behaves differently?