More of a flow chart than a state machine, don't you think?
xpe opened this issue · comments
State machines are nice, but I don't think the HTTP Decision Diagram is a state machine. While some
suggest that such an approach is a state machine, I think that stretches the term. A classic example of a state machine is a system controlling a traffic light. It has internal state that changes over time; it is more than a flow chart. This MathWorks documentation goes into some detail:
Difference Between Flow Charts and State Transition Diagrams
A flow chart is used for combinatorial design. It is a stateless flow chart
because it cannot maintain its active state between updates. As a result, a
flow chart always begins executing from a default transition and ends at a
terminating junction (a junction that has no valid outgoing transitions).By contrast, a state transition diagram is used for sequential design. It
stores its current state in memory to preserve local data and activity between
updates. As a result, state diagrams can begin executing where they left off
in the previous time step, making them suitable for modeling reactive or
supervisory systems that depend on history. In these kinds of systems, the
current result depends on a previous result.
By the way, I really like what you are doing, and I'm building a Clojure implementation based on your decision diagram that I hope to open source fairly soon. I just like being clear with terms. I studied electrical engineering back in college, and I think perhaps people are too eager to label things as state machines when they sometimes they are just flow charts.
Well, https://github.com/for-GET/http-decision-diagram hopefully doesn't talk about "state machines" (on purpose).
As for this repo - flowcharts, workflows, activity diagrams, - usually get implemented via a state-machine module, thus the FSM notion. A flowchart is a subset concept of a state machine.
Having said that, there is at least one situation that is not modelled (again, on purpose) in the decision diagram, but one that should be handled, making the implementation closer to a state machine: socket closed. At each and every state there is at least one extra possible input: client terminated the request; can I interrupt the flow?
The other aspect of a state machine, the possibility of a cyclic graph, is less possible but can be observed nevertheless around expects_continue.
All in all,
- the diagram doesn't (or to be safe: should not) mention state machine, other than as a implementation alternative
- this repo implements the diagram as an Finite SM (mind the highlight)
Please point me (or file some PRs) with corrections, as you see fit. (I also like clear terms)
PS: I don't know how you're implementing this, but hopefully you're deriving the flow solely from the Cosmogol/JSON output (allowing the flow to be remodelled solely by re-designing the diagram, possibly adding new callbacks).
That's an interesting point about expects_continue, but I don't think it makes a cycle. My take on that is that the flow chart restarts at the entry point on the second request. Best I can tell, the HTTP protocol is stateless -- though I haven't read all the specs (yet???) like you have.
Nope. There's no first and second request. It's just one request that splits in two (theoretically; due to bad implementations many HTTP clients/server ignore that and send/receive payload anyways) in a timeline of 2 responses - one intermediary (100 Continue) and one final.