![]() ![]() * %xB-F are reserved for further control frames * %x3-7 are reserved for further non-control frames So for example, break on the 4 bit Opcode, here are the different types of break possible: A developer should be able to trigger the debugger to break when a particular frame pattern is detected. For example, show frames that represents STOMP payloads and can decode the stomp control frames.ĥ) We should provide developers with a means for setting BREAKPOINTS that are based on frame attributes, and not on the API itself. Then there are some interesting additional features we can provide:Ĥ) Protocol upgrade intelligence: make the grouping UI extensible so that someone could correlate to upgraded protocol attributes. Bug 1197903 outlines the need for the JSON parser.ġ) 2) and 3) are part of the minimum viable product. As a bonus we could also make sure we can at least highlight JSON objects in the frames. One way to do this is to overlay the API events on top of a frame timeline. Similarly, a ws.onmessage event should be correlated to all the associated frames. And if an error takes place, we need to show the user what frame caused the error. The network doesn't produce an error, the WS API does. ![]() ![]() Perhaps the most useful example would be an error message. This means we need to provide a way for the developer to be able to go from a websocket API event to the frames associated with that event. Only perf issue here is whether displaying data content on payload frames would cause excessive memory usage and/or excessive frame rate slow downĢ) We should provide developers with the ability to BRIDGE the websocket API with the frames. At the very least, we must provide developers with a view of the basic six frames and their associated meta-data. There are currently six frame types that are identified by RFC 6455, plus 10 more open for future expansion. US 927481 covers the websocket frame inspection. Note that in the future, websocket connections in workers will make the discovery process a little more complicated from a presentation point of view. Obviously, the frames should be grouped by WS connection, and the WS connections should be discoverable (US 1203308). If we were to put the messages in there, we are effectively instrumenting the websocket API, when instead we should be inspecting the network itself, since that is what the network inspector is meant to be. ![]() You just put a break on the websocket API calls. Putting messages into the network inspector is totally redundant and useless because the developer can already get this information via the debugger, there's really no use for it in the network inspector. We need to provide developers with transparency for RFC 6455. RFC 6455 specifies how websocket works, what goes over the network are frames, not what the websocket API interprets. At a high level, here are the features we need:ġ) The core information that belongs in the network inspector for websocket MUST be frames, and not messages. Summary: our tools should allow developers to visualize the websocket connections, this means providing transparency for the frames as defined in RFC 6455, and providing a way to correlate the frames and the events produced by the browser WS API implementation. ![]()
0 Comments
Leave a Reply. |