Document DAP features that are not yet implemented in all IDEs

[remss]

The debug adapter protocol is independent from VS Code and contains quite a few features that are not implemented in VS Code but exist in VS or VS for Mac. In the VS Code release notes you always try to clearly state whether a new DAP feature is implemented in VS Code or not. But it is difficult to review all release notes to find if a feature of the DAP is implemented or not.

For now the only way I see is to test the feature and see if it does something. But when it doesn't I'm not sure if the feature is not implemented or if I misuse the DAP.

Maybe some labels like "VSCode-only" or "VS-only" in the DAP documentation could help developers what is available for the IDE they target ?

[PavelSosin]

This issue is actually comprise 2 different issues:

• 1. For which scenario the message is relevant
• 2. In which IDE and DA the message is implemented There is no 100% suitable IDEs for every goal. This was also mentioned by Erich Gamma in his Cloud native IDE proposal. Every developer can choose most suitable for his/her goals front-end. IDE infrastructure provides UI backend (VSCode, Theia) and platform services (git, DevOps, Team development support, Doc generators, set of LSP servers and Debugging servers. Infrastructure can be local, cloud or hybrid.

The IDE purpose is to serve in certain scenario:

1. Local desktop application development
2. Consumer and businesses application development
3. Native cloud micro-services development
4. • (new) Cloud gaming development
5. To avoid dealing with very big matrix I propose to define 2 protocol layers: Core protocol applicable in all scenaria and Protocol extension used in certain scenario and implemented by certain IDEs Core protocol is mandatory for implementation by all IDE and DA Protocol extension can be implemented by certain IDE and DA. If certain IDE doesn't support certain message it doesn't harm its DAP protocol compatibility. Optional messages / message sequences should be communicated via Server and Client capabilities. Default values of capability shall be chosen according expected percentage of developers for which this feature is required

[PavelSosin]

SAP Web IDE doesn't support any low-level debugging features: Register access Memory read Dissassembly SAP WebIDE provides more fine-grained resolution for language context: language+projectType= contentType. The reason is that the same language can be used at more than one layer of application stack but with absolutely different built-in libraries: Typescript for SAPUI5 and typescript for Nodejs

[PavelSosin]

@weinand - Since in most cases IDE has debugger feature built on top of low-level debugging protocols or debugger server internally uses low-level debugging protocol I think it will be the correct to add reference map to corresponding low-level protocol call to justify request / notification usage.