Debug Adapter Protocol の新しい拠点
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つ以上のブレークポイントを設定します。開発ツールは Debug Adapter に
setBreakpointsリクエストを送信し、Debug Adapter はブレークポイントを gdb デバッガーに登録します。 - 次にユーザーは**続行**ボタンを押して実行を再開します。ツールは Debug Adapter に
continueリクエストを送信し、Debug Adapter はこれを対応する gdb コマンドに変換します。 - しばらくしてブレークポイントがヒットし、Debug Adapter は gdb から通知を受け取り、これを開発ツールに送信される DAP の
stoppedイベントに変換します。 - この
stoppedイベントに応答して、開発ツールはUIを更新し、スタックトレースビューを表示します。これによりstacktraceリクエストがトリガーされ、個々のスタックフレームに表示されるすべての情報が返されます。 - ユーザーが1つのスタックフレームを選択すると、開発ツールは
variablesリクエストでそのフレームの変数を要求します。
歴史的な理由から、DAP は（現在は廃止された）V8 デバッグプロトコルに触発された 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スキーマとしてのプロトコル仕様。
- プロトコル仕様から自動生成された詳細なドキュメント。
- プロトコルを実装するDebug Adapter。
- プロトコルをホストする開発ツール。
- プロトコルをサポートするSDK。
- バグ、機能リクエスト、プルリクエストは、新しいリポジトリのIssuesセクションで作成できます。
古い場所では、DAP用の3つのnpmモジュールのソースが引き続きホストされます。
今後の展開
Debug Adapter Protocol はすでにかなりの期間利用可能であったため、新しいウェブサイトへの移行は、真の創設というよりは、単に新しい拠点への移転に過ぎません…
DAP の既存および将来のすべてのユーザーが、私たちの新しい拠点にアクセスし、そこで協力を継続していただくことを歓迎します。例えば、これらのMarkdownファイルに対してGitHubでプルリクエストを送信することで、サポートツールと実装のリストを最新の状態に保つのに役立つことができます：Debug Adapter、ツール、およびSDK。
VS Codeチームを代表して: ハッピーコーディング！
André Weinand - Twitter の @weinand