I think any additional documentation of the HTTP state machine and its transitions would be very useful. However, I'd much prefer it to be in plant-UML format. As a first pass, just sequencing the basic states would be good. If needed, sub-state diagrams showing particular states would be the next step.
On Wed, Dec 4, 2019 at 10:30 AM Walt Karas <wka...@verizonmedia.com.invalid> wrote: > It probably would be hard to diagram it in 3-dimensional space, much less > two. But maybe we could do a table with the columns Start State, Event, > New State, Notes. Perhaps we could create the source document in JSON > format or something. It would be nice if we could convert it with code to > RST, but also load it into a spreadsheet. So we could sort on either Start > State or New State. > > The problem with real-world state machines is that they don't really have a > small number of discrete states. They have a state vector with multiple > variables, with a huge number of potential states. An often-effective > cheat is to make fake distinctions between events that really reflect state > differences. For example, considering "receive bytes when buffer empty" > and "receive bytes when buffer not empty" as distinct events. But maybe > our state machine is so complex it would overwhelm this cheat strategy. >
