You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given the way we present our DebugConnectionsOutgoingData and DebugConnectionsIncomingData, there are a few ways we could make this easier to grok.
We could process the CR+LF pairings in a way that we don't end up splitting a CR on one side of a response where the LF then shows up.
We could try to block in/out data, starting on new lines, and presented in a grouping manner perhaps more consistent with any client with a debugging mode: BeipMU is the only one I know of with such a debugging tool, so that is probably by default the one to match with.
Similarly we could pair our color coding of these blocks to better "match up" what debugging info we see on the server output paired to what debugging info we see from the client. Like if the client is using red for a block header of "Received..." (from the server) then it may make sense to ensure our server sending is blocked red, for a nice cognitive support link.
Basically, if both client and server network debugging outputs are easily reconciled against each other, and easy to see they agree, then it can help build trust and understanding of both those tools successfully showing us the whole picture.
The text was updated successfully, but these errors were encountered:
Given the way we present our
DebugConnectionsOutgoingData
andDebugConnectionsIncomingData
, there are a few ways we could make this easier to grok.Basically, if both client and server network debugging outputs are easily reconciled against each other, and easy to see they agree, then it can help build trust and understanding of both those tools successfully showing us the whole picture.
The text was updated successfully, but these errors were encountered: