Neues Zuhause für das Debug Adapter Protocol

7. August 2018 André Weinand, @weinand

Ein Ziel des Juli-Meilensteins war es, das Debug Adapter Protocol – das sich in einem etwas obskuren GitHub-Projekt versteckte – auf eine prominentere Website zu verlagern (siehe Feature-Anfrage #19636).

Dieser Blog gibt einige Hintergründe zu Protokollen, dem Debug Adapter Protocol und den Hintergründen der Verlagerung.

Warum die Notwendigkeit der Entkopplung mit Protokollen?

Aus einem anderen Blog

"Visual Studio Code ist ein Editor für jeden Entwickler, egal welche Programmiersprache Sie verwenden."

Dieses Versprechen basiert auf (mindestens) zwei Säulen

• Einer erweiterbaren Tool-Plattform und einem Ökosystem, in das jeder einfach beitragen kann.
• Technologie, die es einfach macht, hervorragende Tool-Unterstützung für jede Programmiersprache hinzuzufügen.

Die Unterstützung einer Programmiersprache durch ein Entwicklungswerkzeug bedeutet

• Umfangreiche Bearbeitungsunterstützung basierend auf einem tiefen Verständnis einer Sprache (auch bekannt als "Sprachintelligenz").
• Debugging-Unterstützung für die Sprache, integriert in das Bearbeitungswerkzeug.

Letzteres mag für einige überraschend kommen, aber wir waren immer fest davon überzeugt, dass Debugging ein integraler Bestandteil des Ortes ist, an dem der Quellcode geschrieben wird: dem Editor. Debugging ist ein wichtiger Teil der "inneren Schleife" der Entwicklung.

Aber das Hinzufügen eines Debuggers für eine neue Sprache zu einer IDE oder einem Editor ist ein erheblicher Aufwand, da die Liste der Standard-Debugging-Funktionen nicht klein ist

• Source-, Funktions-, bedingte, Inline-Breakpoints und Logpoints.
• Variablenwerte, die in Tooltips oder direkt im Quellcode angezeigt werden.
• Unterstützung für mehrere Prozesse und Threads.
• Navigation durch komplexe Datenstrukturen.
• Watch-Ausdrücke.
• Debug-Konsole für interaktive Auswertung mit Autovervollständigung (REPL).

Die Implementierung dieser Funktionen für eine neue Sprache ist nicht nur ein erheblicher Aufwand, sondern es ist auch frustrierend, dass diese Arbeit für jedes Entwicklungswerkzeug wiederholt werden muss, da jedes Werkzeug unterschiedliche APIs zur Implementierung seiner Benutzeroberfläche verwendet.

Dies führt zu viel duplizierter Funktionalität (und Implementierung), wie die blauen Kästen im folgenden Bild zeigen

Als wir mit der Arbeit an Visual Studio Code begannen, hatten wir immer vor, die "Frontend"-Benutzeroberfläche so weit wie möglich von der sprachspezifischen "Backend"-Implementierung zu entkoppeln. Dies wollten wir sowohl für Sprachintelligenz als auch für Debugging-Unterstützung tun.

Heute glauben wir, dass wir dieses ehrgeizige Ziel erreicht haben

Wir haben zwei abstrakte Protokolle erstellt, die die Entkopplung der Editing- und Debugging-Benutzeroberflächen im "Frontend" von der sprachspezifischen Intelligenz und Debugging-Funktionalität, die von "Backend"-Komponenten bereitgestellt wird, ermöglichen.

Das "tiefe Verständnis einer Sprache" wird durch das Language Server Protocol (LSP) bereitgestellt, und die "Debugging-Unterstützung" durch das Debug Adapter Protocol (DAP).

Das Debug Adapter Protocol

Die Idee hinter dem Debug Adapter Protocol ist, ein abstraktes Protokoll zu standardisieren, wie die Debugging-Komponente eines Entwicklungswerkzeugs mit konkreten Debuggern oder Laufzeiten kommuniziert.

Da es unrealistisch ist anzunehmen, dass bestehende Debugger oder Laufzeiten dieses Protokoll bald übernehmen würden, haben wir stattdessen eine vermittelnde Komponente entwickelt, die die Aufgabe übernimmt, eine bestehende Debugger- oder Laufzeit-API an das Debug Adapter Protocol anzupassen. Diese Vermittlungskomponente wird zum Debug Adapter, was den Namen des Protokolls erklärt: Debug Adapter Protocol.

Hier ist ein Beispiel, wie ein Entwicklungswerkzeug das DAP verwenden könnte, um mit einem Debug Adapter für den beliebten "gdb"-Debugger zu kommunizieren

Wir gehen davon aus, dass der Benutzer bereits eine Debug-Sitzung gestartet hat, aber gerade am Einstiegspunkt seines Programms angehalten hat und einen Breakpoint setzen (und später treffen) möchte.

• Der Benutzer setzt einen oder mehrere Breakpoints in einer bestimmten Quelldatei, indem er in die Breakpoint-Gutter klickt. Das Entwicklungswerkzeug sendet eine setBreakpoints-Anfrage an den Debug Adapter, der den Breakpoint beim gdb-Debugger registriert.
• Der Benutzer drückt dann die Schaltfläche Weiter, um die Ausführung fortzusetzen. Das Werkzeug sendet eine continue-Anfrage an den Debug Adapter, der dies in den entsprechenden gdb-Befehl übersetzt.
• Einige Zeit später wird der Breakpoint erreicht, und der Debug Adapter erhält eine Benachrichtigung von gdb und übersetzt diese in ein DAP stopped-Ereignis, das an das Entwicklungswerkzeug gesendet wird.
• Als Reaktion auf dieses stopped-Ereignis aktualisiert das Entwicklungswerkzeug seine Benutzeroberfläche und zeigt eine Stack-Trace-Ansicht an. Dies löst eine stacktrace-Anfrage aus, die alle Informationen zurückgibt, die für die einzelnen Stack-Frames angezeigt werden.
• Wenn der Benutzer einen Stack-Frame auswählt, fordert das Entwicklungswerkzeug die Variablen dieses Frames mit einer variables-Anfrage an.

Aus historischen Gründen verwendet DAP ein JSON-basiertes Wire-Format, das vom (jetzt veralteten) V8 Debugging Protocol inspiriert ist. Bitte beachten Sie, dass dieses Format dem in LSP verwendeten JSON-RPC ähnelt, aber nicht damit kompatibel ist.

Nach diesem kurzen Beispiel der DAP-Kommunikation, lassen Sie uns die Merkmale des DAP-Ansatzes überprüfen

Das Bild zeigt zwei wichtige Vorteile des DAP-Ansatzes

• Debug-Adapter können zwischen verschiedenen Entwicklungswerkzeugen geteilt werden, was zur Amortisation ihrer Entwicklungskosten beiträgt.
• Das Debug Adapter Protocol ist nicht an VS Code gebunden und kann als Grundlage für eine generische Debugger-Benutzeroberfläche in anderen Entwicklungswerkzeugen verwendet werden.

Diese Merkmale ähneln denen des Language Server Protocols, das 2016 auf seiner eigenen Website veröffentlicht wurde.

Ein neues Zuhause für das DAP

Nun haben wir dem Debug Adapter Protocol nachgezogen und die DAP-Spezifikation von ihrem alten Standort auf eine neue Website https://msdocs.de/debug-adapter-protocol und ein entsprechendes Repository https://github.com/microsoft/debug-adapter-protocol verlagert.

Diese Verlagerung soll betonen, dass das Debug Adapter Protocol nicht spezifisch für Visual Studio Code ist. Zum Beispiel unterstützt Visual Studio jetzt auch dieses Protokoll.

Am neuen Standort bieten wir

• Eine Übersicht und Einführung in das Protokoll.
• Die Protokollspezifikation als maschinenlesbares JSON-Schema.
• Detaillierte Dokumentation, die automatisch aus der Protokollspezifikation generiert wird.
• Debug-Adapter, die das Protokoll implementieren.
• Entwicklungswerkzeuge, die das Protokoll hosten.
• SDKs, die das Protokoll unterstützen.
• Bugs, Feature-Anfragen und Pull-Requests können im Abschnitt Issues des neuen Repositories erstellt werden.

Der alte Standort wird weiterhin den Quellcode für die drei npm-Module für DAP hosten

• vscode-debugprotocol
• vscode-debugadapter
• vscode-debugadapter-testsupport

Was kommt als Nächstes?

Da das Debug Adapter Protocol bereits seit einiger Zeit verfügbar ist, ist die Verlagerung auf eine neue Website keine wirkliche Neuerung, sondern nur ein Umzug in ein neues Zuhause...

Wir möchten alle bestehenden und zukünftigen Benutzer des DAP einladen, unser neues Zuhause zu besuchen und die Zusammenarbeit dort fortzusetzen. Sie können zum Beispiel dazu beitragen, die Liste der unterstützenden Werkzeuge und Implementierungen aktuell zu halten, indem Sie Pull-Requests auf GitHub gegen diese Markdown-Dateien einreichen: Debug-Adapter, Werkzeuge und SDKs.

Im Namen des VS Code-Teams: Happy Coding!

André Weinand -  @weinand auf Twitter