The table might be at least a good first step towards getting a diagram. I thinking it would only work as multiple diagrams. With boxes that say "To diagram n" with a single arrow going in, or "From diagram n" with a single arrow coming out. Maybe that's what you mean by sub-state diagrams. Or are the HttpSM states already grouped into "higher level" states?
On Thu, Dec 5, 2019 at 10:38 AM Alan Carroll <solidwallofc...@verizonmedia.com.invalid> wrote: > 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. > > >
