| Re: [theia-dev] Debugger architecture musings |
|
You got me at "simplify".
Regarding 1) if we move the DebugService to the frontend then debug sessions will have even more reasons to be destroyed. If we want persistence of those, we need to at least persist the debug adapter processes in the backend. Might be out of scope of your
idea, I don't really know. But I think it is still a good idea to move as much of the state we can (given what makes sense) into the browser.
Agreed with 2) it looks like it was done this way to get around what you described in 1).
From: theia-dev <theia-dev-bounces@xxxxxxxxxxx> on behalf of Thomas Mäder <tmader@xxxxxxxxxx>
Sent: Friday, October 8, 2021 9:58 AM To: theia-dev@xxxxxxxxxxx <theia-dev@xxxxxxxxxxx> Subject: [theia-dev] Debugger architecture musings Hi Folks,
I've been looking at the Theia debugger recently and are a couple of things which are odd:
1. The DebugService lives on the back-end.
I believe the Idea originally was to reconnect to debug sessions after doing a refresh. But since the DebugService lives in connection scope and kills all sessions upon dispose, I don't think that will ever work anyway. So why not just move the DebugService to the front end? It's how most other services work. 2. There is a "PluginDebugService" which replaces the DebugServiceImpl, but still forwards to that implementation. That quite different from other services, where we have a general service that can be extended with contributions with specialized contributions
for stuff contributed via VSCode API. I believe this choice is because of the first point above.
Wondering if others agree with this assessment and whether it would be worthwhile to simplify the architecture along these lines? Comments, please?
/Thomas
|