デバッグアダプタープロトコルの新しいホーム
2018年8月7日 André Weinand, @weinand
7月のマイルストーンの目標の一つは、**Debug Adapter Protocol** (やや分かりにくいGitHubプロジェクトの中に隠れていた) を、より目立つウェブサイトに移行することでした (機能リクエスト#19636参照)。
このブログでは、プロトコル、Debug Adapter Protocol、そして移行の動機について背景を説明します。
なぜプロトコルによるデカップリングが必要なのか？
別のブログから
「Visual Studio Codeは、どんなプログラミング言語を使っても、あらゆる開発者のためのエディターです。」
この約束は（少なくとも）2つの柱に基づいています。
- 誰もが簡単に貢献できる拡張可能なツールプラットフォームとエコシステム。
- あらゆるプログラミング言語に優れたツールサポートを簡単に追加できるテクノロジー。
開発ツールからプログラミング言語をサポートすることは、次のことを意味します。
- 言語の深い理解に基づいた豊富な編集サポート（別名「言語インテリジェンス」）。
- 編集ツールに統合された言語のデバッグサポート。
後者は一部の人には驚きかもしれませんが、デバッグがソースコードが書かれる場所であるエディターの不可欠な部分であると私たちは常に固く信じていました。デバッグは開発の「インナーループ」の重要な部分です。
しかし、新しい言語のデバッガーをIDEやエディターに追加することは、標準のデバッグ機能のリストが少なくないため、かなりの労力です。
- ソース、関数、条件付き、インラインブレークポイント、およびログポイント。
- ホバーまたはソースにインラインで表示される変数値。
- マルチプロセスおよびマルチスレッドのサポート。
- 複雑なデータ構造のナビゲート。
- ウォッチ式。
- オートコンプリート（REPL）による対話型評価のためのデバッグコンソール。
新しい言語のためにこれらの機能を実装することは、かなりの労力であるだけでなく、各ツールがユーザーインターフェースの実装に異なるAPIを使用するため、この作業を各開発ツールごとに繰り返さなければならないことに不満が募ります。
これは、次の図の青いボックスで示されているように、多くの機能（および実装）の重複につながります。
Visual Studio Codeの作業を開始したとき、私たちは常に「フロントエンド」UIと、言語固有の「バックエンド」実装を可能な限り分離することを想定していました。私たちは、言語インテリジェンスとデバッグサポートの両方でこれを実現したいと考えていました。
今日、私たちはこの野心的な目標を達成したと信じています。
私たちは、「フロントエンド」の編集およびデバッグのユーザーインターフェースを、「バックエンド」コンポーネントが提供する言語固有のインテリジェンスおよびデバッグ機能から分離するための2つの抽象プロトコルを作成しました。
「言語の深い理解」はLanguage Server Protocol (LSP) によって、そして「デバッグサポート」はDebug Adapter Protocol (DAP) によって表面化されます。
Debug Adapter Protocol
Debug Adapter Protocolの背後にあるアイデアは、開発ツールのデバッグコンポーネントが具体的なデバッガーまたはランタイムと通信する方法について、抽象プロトコルを標準化することです。
既存のデバッガーやランタイムがすぐにこのプロトコルを採用すると仮定するのは非現実的であるため、代わりに既存のデバッガーまたはランタイムAPIをDebug Adapter Protocolに適応させる役割を担う**中間**コンポーネントを設計しました。この中間コンポーネントがDebug Adapterとなり、プロトコル名であるDebug Adapter Protocolの由来となっています。
開発ツールがDAPを使用して、人気のある「gdb」デバッガー用のDebug Adapterと通信する例を次に示します。
ユーザーはすでにデバッグセッションを開始しているが、現在はプログラムのエントリポイントで停止しており、ブレークポイントを設定（後にヒット）したいと考えていると仮定します。
- ユーザーは、ブレークポイントガターをクリックして、特定のソースファイルに1つまたは複数のブレークポイントを設定します。開発ツールは`setBreakpoints`リクエストをDebug Adapterに送信し、Debug Adapterはgdbデバッガーにブレークポイントを登録します。
- 次に、ユーザーは**続行**ボタンを押して実行を再開します。ツールは`continue`リクエストをDebug Adapterに送信し、Debug Adapterはこれを対応するgdbコマンドに変換します。
- しばらくすると、ブレークポイントにヒットし、Debug Adapterはgdbから通知を受け取り、これをDAPの`stopped`イベントに変換して開発ツールに送信します。
- この`stopped`イベントに応答して、開発ツールはUIを更新し、スタックトレースビューを表示します。これにより、`stacktrace`リクエストがトリガーされ、個々のスタックフレームに表示されるすべての情報が返されます。
- ユーザーがいずれかのスタックフレームを選択すると、開発ツールは`variables`リクエストでそのフレームの変数を要求します。
歴史的経緯により、DAPは（現在は廃止された）V8 Debugging Protocolに触発されたJSONベースのワイヤーフォーマットを使用しています。このフォーマットはLSPで使用されているJSON-RPCと似ていますが、互換性はありませんのでご注意ください。
DAP通信の短い例の後、DAPアプローチの特徴を確認しましょう。
この図は、DAPアプローチの2つの重要な利点を示しています。
- Debug Adapterは異なる開発ツール間で共有できるため、開発コストを償却するのに役立ちます。
- Debug Adapter ProtocolはVS Codeに限定されず、他の開発ツールで汎用デバッガーUIの基盤として使用できます。
これらの特性は、2016年に独自のウェブサイトで公開されたLanguage Server Protocolの特性と似ています。
DAPの新しいホーム
今回、私たちはDebug Adapter Protocolについても同様に、DAP仕様を古い場所から新しいウェブサイトhttps://microsoft.github.io/debug-adapter-protocol、および対応するリポジトリhttps://github.com/microsoft/debug-adapter-protocolに移行しました。
この移行は、Debug Adapter ProtocolがVisual Studio Codeに特化したものではないことを強調すべきです。たとえば、Visual Studioも現在、このプロトコルをサポートしています。
新しい場所では、以下を提供しています。
- プロトコルの概要と導入。
- 機械処理可能なJSONスキーマとしてのプロトコル仕様。
- プロトコル仕様から自動生成された詳細なドキュメント。
- プロトコルを実装するデバッグアダプター。
- プロトコルをホストする開発ツール。
- プロトコルをサポートするSDK。
- バグ、機能リクエスト、プルリクエストは、新しいリポジトリのIssuesセクションで作成できます。
古い場所は、DAPの3つのnpmモジュールのソースを引き続きホストします。
次は何？
Debug Adapter Protocolはすでにかなりの期間利用可能であったため、新しいウェブサイトへの移行は実際には誕生ではなく、単に新しいホームへの移動にすぎません...
DAPの既存および将来のすべてのユーザーを新しいホームに招待し、そこで協力を継続したいと考えています。たとえば、GitHubでこれらのMarkdownファイルにプルリクエストを送信することで、サポートツールと実装のリストを最新の状態に保つのに役立ちます: Debug Adapters, Tools, および SDKs.
VS Codeチームを代表して: ハッピーコーディング！
André Weinand - Twitterの@weinand