Standardise the ability for client/DA to use URIs in place of file paths (enabling debugging of non-file:/ sources) about debug-adapter-protocol HOT 17 OPEN

I'm not sure that support URIs with custom schemes introduces any editor-specific restrictions. Considering:

• In the case that a client requests the debugger, through its launch configuration, to debug content that includes or lives on a foreign scheme, it will be aware of that scheme.
• In the case that a client is unaware of the foreign scheme, this implies it cannot edit files that live on that scheme. Therefore, if a DA returns sources on a foreign scheme, showing read-only contents of that file via the source request should be sufficient.

If we support this, I would be happy to adopt it in the JavaScript debugger. For example, a euser can debug JavaScript on remote URIs (e.g. https://example.com) and sourcemaps can generate URIs of virtual files (webpack-internal://... URIs for example.) Today the debugger munges these into a path-like structure with a non-zero sourceReference, but preserving the original URI would be clearer to users and provide better navigation of loaded sources.

from debug-adapter-protocol.

VS Code has an API (registerTextDocumentContentProvider) that lets an extension supply content for a custom scheme. The idea is that these work together - an editor might not be restricted only to file:///-based content, but might be able to handle virtual documents. That's why part of my suggestion was for the client to tell the server which URI schemes it can read documents for (it would be entirely opt-in and not require clients to handle URIs).

Eg., if I call registerTextDocumentContentProvider in my VS Code extension and say I can provide content for danny:/ URIs, the VS Code debug client could pass ['file', 'danny'] in the capabilities as schemes it can handle documents for, and the debug adapter would then know that if it has sources that are danny: URIs it could use those URIs in Source responses.

This is all very well, but would require a client VS code extension, and a custom extension for any other editor per debug adapter that uses that functionality. That goes against the main selling point of the protocol:

The idea behind the Debug Adapter Protocol (DAP) is to abstract the way how the debugging support of development tools communicates with debuggers or runtimes into a protocol. [...]
Debug Adapters can be re-used across multiple development tools which significantly reduces the effort to support a new debugger in different tools.

There would need to be a mechanism in the protocol to retrieve contents for custom scheme's, but the source already kinda is that.

from debug-adapter-protocol.

I'm not sure I agree. The protocol supports many opt-in capabilities that add functionality to clients that support it. The protocol is not intended to restrict all debuggers and clients to only functionality that all other debuggers and clients can support.

So far no client capabilities require any language-awareness and a client can implement them reasonably in a generic way that's usable with any debug adapter. That's not possible for custom scheme's without some standard retrieval mechanism.

All of VS Code and LSP has been built using Uris so that the file:/// scheme doesn't have to be special. VS Code is already handling this and it supports real use cases. I don't really understand the resistance to this - it adds zero work to clients that do not want to support it.

Because as @puremourning pointed out, that language servers use URIs with custom scheme's without providing a standardized way to look up the document is already causing friction in other clients. See also microsoft/language-server-protocol#336

from debug-adapter-protocol.

The fix is to have a mechanism for servers to know what a client supports (and in the meantime, for servers not to return non-file URIs), not to prevent the ability to have these custom schemes

This is already the case for the most part. They're still problematic because users wonder why something doesn't work in <editor-x> when it works in vscode.

Debug adapters might return garbage URIs the client cannot handle" does not seem like an argument against this functionality

That's not the concern or the argument I made. My concern is that there is no way for a client to implement this generically. It would need scheme specific implementations for each debug adapter that starts using this functionality to reach feature parity with vscode. That's getting back to dedicated implementations per editor per debug adapter - the problem DAP and LSP claimed to solve.

This has already been a major pain point with LSP and its undefined client commands and it was nice that DAP didn't suffer from this problem. It would be really disappointing to see this change

from debug-adapter-protocol.

In VS Code, we do try to parse the string field as a URI. That happens here https://github.com/microsoft/vscode/blob/aae2b0d4c589c367437411b5e6eb8ddf0386476f/src/vs/workbench/contrib/debug/common/debugSource.ts#L133

from debug-adapter-protocol.

What should a client do with a random URI? We have this problem in LSP where server spams out 'jdt://' and client has no clue what to do with that. The source request is an elegant solution.

from debug-adapter-protocol.

@roblourens

In VS Code, we do try to parse the string field as a URI. That happens here

Ah, that's interesting - I'll do some testing of that. It should really be part of the spec before debug adapters rely on it though. I can add a flag to only send URIs for VS Code in the meantime, but I think I'd only want to do it if there's a path to it being standard.

@puremourning

What should a client do with a random URI?

VS Code has an API (registerTextDocumentContentProvider) that lets an extension supply content for a custom scheme. The idea is that these work together - an editor might not be restricted only to file:///-based content, but might be able to handle virtual documents. That's why part of my suggestion was for the client to tell the server which URI schemes it can read documents for (it would be entirely opt-in and not require clients to handle URIs).

Eg., if I call registerTextDocumentContentProvider in my VS Code extension and say I can provide content for danny:/ URIs, the VS Code debug client could pass ['file', 'danny'] in the capabilities as schemes it can handle documents for, and the debug adapter would then know that if it has sources that are danny: URIs it could use those URIs in Source responses.

The source request is an elegant solution.

It has the issues I mentioned above - the client can't relate these sources to sources that the user discovered when there was no debug session (via language server), or across debug sessions (because they have no stable identifiers, just random sourceReferences). It's very confusing for a user to Go-to-Definition on something, add a breakpoint, and then while debugging be shown another copy of the same file (which the editor tracks a completely separate set of breakpoints for, even if the debugger is treating them the same).

from debug-adapter-protocol.

@roblourens I just tested it, and it works as you described - this is great (but I think still needs to become standard). Thank you for highlighting it! :-)

from debug-adapter-protocol.

This is all very well, but would require a client VS code extension, and a custom extension for any other editor per debug adapter that uses that functionality.

All it requires is that the client knows how to get resources from a scheme. VS Code already has this support, and it seems likely LSP will get it.

That goes against the main selling point of the protocol:

I'm not sure I agree. The protocol supports many opt-in capabilities that add functionality to clients that support it. The protocol is not intended to restrict all debuggers and clients to only functionality that all other debuggers and clients can support.

There would need to be a mechanism in the protocol to retrieve contents for custom scheme's, but the source already kinda is that.

Source does it in a way that is debug-session specific and cannot interact with sources provided by any other source in the editor. This has many drawbacks that I have mentioned above. Why should debugging only work properly if your source files are on the local physical disk of a machine? Why shouldn't debugging be able to work with custom remote filesystems or when running in sandboxes or browsers with only virtual resources?

All of VS Code and LSP has been built using Uris so that the file:/// scheme doesn't have to be special. VS Code is already handling this and it supports real use cases. I don't really understand the resistance to this - it adds zero work to clients that do not want to support it.

from debug-adapter-protocol.

So far no client capabilities require any language-awareness and a client can implement them reasonably in a generic way that's usable with any debug adapter.

There's no language-awareness required here. Just that a client is able to tell a DA what URI schemes (besides file:/) it is able to fetch content for and that the spec allows for returning those URIs instead of paths everywhere. Yes, it's only useful when a client has some other part to this, but I don't see why that's a reason not to do it - it does not need any language-specific work on part of the client/editor.

That's not possible for custom scheme's without some standard retrieval mechanism.

Sure it is. An editor would not say that it knows how to get "danny:/" documents unless is has some way of getting content. How that happens is entirely up to the editor through its own plugins or configuration. If an editor doesn't have any resource provider registered for the danny:/ scheme, it would never tell the DA that it does, and the DA should never return danny:/ URIs.

Because as @puremourning pointed out, that language servers use URIs with custom scheme's without providing a standardized way to look up the document is already causing friction in other clients.

This doesn't make any sense to me. This is an implementation issue. Servers should not return URIs that it they don't know a client can handle. The fix is to have a mechanism for servers to know what a client supports (and in the meantime, for servers not to return non-file URIs), not to prevent the ability to have these custom schemes. LSP servers doing bad things is not a reason not to support new features that provide better debugging experiences.

The LSP request above is exactly what I want to implement (an LSP equiv of VS Code's API). But there's no reason that supporting arbitrary URIs here in DAP requires any specific implementation (in LSP or otherwise). That's an implementation detail the debugger should not need to know about. If a debug adapter and the corresponding LSP server (or VS Code extension, or some other functionality of an editor) both agree they know how to use a custom URI scheme (which has been made up by a language), why shouldn't they be able to use it?

This already all exists and works in VS Code today, I really don't understand what drawbacks there are to making it standard. "Debug adapters might return garbage URIs the client cannot handle" does not seem like an argument against this functionality - they can also return invalid file paths and invalid DAP responses. The spec can't protect you from misbehaving implementations.

from debug-adapter-protocol.

@connor4312

In the case that a client requests the debugger, through its launch configuration, to debug content that includes or lives on a foreign scheme, it will be aware of that scheme.

In my case, the launch program is not on the custom scheme, it's for additional sources that don't exist on disk. I think it would be better as part of capabilities (since the editor already knows which schemes it can handle). I actually just found this in InitializeRequestArguments:

  /**
   * Determines in what format paths are specified. The default is `path`, which
   * is the native format.
   * Values: 'path', 'uri', etc.
   */
  pathFormat?: 'path' | 'uri' | string;

This is odd, because it's a single value (not an array) so can't indicate support for both paths and URIs, and it allows for an arbitrary string with no explanation of what it is.

My suggestion would be that specific URI schemes are provided instead (and perhaps pathFormat is deprecated?):

  /**
   * Determines the schemes the client supports in URIs used for paths.
   *
   * If defined, it means the client accepts URI strings in any `path` fields such as `Source.path`.
   */
  pathUriSchemes?: string[]; // ["file", "danny"]

@mfussenegger

This is already the case for the most part. They're still problematic because users wonder why something doesn't work in <editor-x> when it works in vscode.

As an author of LSP and DAP servers used in other editors, I completely sympathise with this - but nothing in my request here requires that other editors get broken. I want this in the spec specifically to make things standard and not VS Code-only. I care very much about the LSP and DAP servers I work on being usable (and as functional as possible) with other editors.

My concern is that there is no way for a client to implement this generically. It would need scheme specific implementations for each debug adapter that starts using this functionality to reach feature parity with vscode.

I don't agree with this. If/when LSP gets support for TextDocumentContentProvider (something I'd like to contribute, but it's no good without debugger support) any editor could have a completely standard LSP server and completely standard debug adapter and no language-specific functionality/plugin and get all of this behaviour. The LSP server would register schemes with the editor, the editor would tell the debug adapter it can read content for those schemes. There's nothing VS Code specific and nothing that requires language-specific plugins.

from debug-adapter-protocol.