Closed rocky closed 9 years ago
The current solution is that status reports from the server (such as a response from a single-step request) include an 'events' field that's a list of all the asynchronous events that happened since the request was received (watch exprs changing, program termination, fork ,etc - every place enqueue_event()
is called on the Perl side). The client goes through that list of events when it gets a response.
The code for using websockets instead would surely be cleaner, but I'm loath to rip out what's currently working unless there's a use-case it can't easily handle.
Makes sense.
I was looking at the V8 debugger protocol and it strikes me that for a web-based interface sockets might be the more appropriate way to go.
The problem with REST is that it is based on a the client issuing a request and getting a single response to that. But events can happen asynchronously. For example, the debugged program can crash unexpectedly. Or it can get a signal that the debugger would like to handle. Or there might be more than one response triggered from a request such as a response and a stack trace from an exception.
Comments?