SourceRequest: Lazily provide local file path?
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
調査の方向性
まず、SourceResponse、SourceReference、Source.Path、SourceLoadedEvent のプロトコル定義とセマンティクスを確認します。issue で提案されている 2 つの動作を比較し、既存のクライアントを壊さずに仕様化できるのがどちらかを判断します。プロトコルの変更と、それに関するクライアントの機能または互換性のルールについて合意し、文書化できれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Description
Right now, adapters have two choices when providing a Source object (in stack trace, etc)
- Provide a local file name that the client can natively open by itself, with
Path - Provide a SourceReference that the client can then query lazily later
The problem with these 2 choices is that clients treat SourceReference-based files as ephemeral for the current session (aka "scripts"), and breakpoints etc will be discarded by the client when it stops/restarts a debugging session.
The usecase I am trying to address is SourceLink (or equivalent) methods of acquiring files that are permanent and immutable. If the client has something like the Parallel stacks view opened, it would be impractical to go do a billion SourceLink requests just to be able to give valid local paths, and so I use the SourceReference approach. However, the current shape of the SourceResponse is that it gives the raw content of the file, and the client will discard any user state it had for that file on restart.
In these usecases where the lazy files are immutable and permanent, I would like to be able to cache them to some adapter-defined arbitrary location and tell the client that the file now has a path as part of a SourceResponse.
Question / feature
This would technically be implementable today by clients if the adapter sends a SourceLoadedEvent alongside the SourceResponse, but this sounds hacky, and AFAIK this really does not fit the interpretation of SourceLoadedEvent of clients (or at least that of VS).
- Could SourceResponse be extended to include a filepath if one can be known lazily?
or another idea
- Could the protocol specify that if a
Sourceobject has bothPathandSourceReference, that the client must not attempt to open the physical file prior to sending aSourceRequest? That would give the opportunity to the adapter to fill the file. Of course with some new flag somewhere at the capabilities level or something, to opt into this new mode.
- 主要言語
- HTML
- スター
- 1.8k
- フォーク
- 173
- 平均マージ
- 7日 7時間
- マージ済み PR（30日）
- 2
環境構築
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/debug-adapter-protocol のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
microsoft/debug-adapter-protocol#633 · コメント 1 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 42/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
microsoft/debug-adapter-protocol#599 · リアクション 8 件 ·
-
under-discussion
難易度 2/5 1〜3時間 初心者へのやさしさ 48/100
microsoft/debug-adapter-protocol#596 · コメント 9 件 ·
microsoft/debug-adapter-protocol の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
メンテナーはふだん 1 日以内に返信
-
good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
vllm-project/vllm-metal#822 ·
メンテナーはふだん 1 日以内に返信
-
[Bug]: chunk_span_bounds and _validated_chunk_spans reject Pydantic models ChunkSpan and AudioFileオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
BasedHardware/omi#19047 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
ditto-assistant/ditto-subnet#2346 ·
メンテナーはふだん 1 日以内に返信