Closed cobratbq closed 4 years ago
This really calls for the state design pattern: https://en.wikipedia.org/wiki/State_pattern
This sounds very valuable. otr4j has proven itself valuable, so I think this is exactly the kind of stuff we need to be thinking about so we can make otr4j provide rock solid private messaging (hence all my work on tests, also).
@languitar yes it does. That was exactly what I was thinking of.
@eighthave My thoughts exactly. Also, I'm glad I took the effort to write tests for the Fragmenter, initially.
Done.
Currently, states are distinguished based solely on the value of certain variables, such as
sessionStatus
in Session.java. Although this works, it is still possible to make a mistake in an implementation in which you do not correctly check all the necessary variables to perfectly distinguish one state from another. This leaves a chance that implementations read or write variables at inappropriate times and as a consequence may leak data or corrupt an otr session unintendedly.There is no reason to believe that this is the case currently, however it would be better to leverage the Java type system to more strictly separate the states. If we separate states in such as way that we can throw exceptions whenever a method is called at an inappropriate time, then we move the risk from the user to the developer, as it would trigger an exception instead of continuing in an inconsistent state. A protocol such as OTR, whose spec clearly describes the expectations in each state, is especially suitable to be structured like this.
As described in the OTR spec, there are 2 state machines (at least):
Of course there significantly changes how the implementation is structured, and increases the chance of Exceptions for imperfect implementations. As such, we should look into this after the initial burst of changes.