SourceRequest: Lazily provide local file path?
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
调研方向
首先审查 SourceResponse、SourceReference、Source.Path 和 SourceLoadedEvent 的协议定义及语义。比较 issue 中提出的两种行为，并确定哪一种可以在不破坏现有客户端的情况下进行规范定义。协议变更及其客户端能力或兼容性规则达成一致并完成文档记录，即视为完成。
由索引模型根据 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 小时
- 30 天内合并 PR
- 2
环境准备
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
microsoft/debug-adapter-protocol 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
-
难度 5/5 一周以上 新手友好度 35/100
microsoft/debug-adapter-protocol#633 · 1 条评论 ·
-
难度 4/5 3-5 天 新手友好度 42/100
-
难度 5/5 一周以上 新手友好度 35/100
microsoft/debug-adapter-protocol#599 · 8 个 reaction ·
-
under-discussion
难度 2/5 1-3 小时 新手友好度 48/100
microsoft/debug-adapter-protocol#596 · 9 条评论 ·
查看 microsoft/debug-adapter-protocol 的全部 Issue
相似的 Issue
-
API Bug
难度 2/5 1-3 小时 新手友好度 78/100
ProjectSidewalk/SidewalkWebpage#5556 ·
维护者通常 1 天内回复
-
backend::vllm diffusion multimodal
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
openai/openai-agents-python#5229 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
priority/4/normal status/needs-triage type/bug/unconfirmed
难度 2/5 1-3 小时 新手友好度 78/100
authelia/authelia#13292 · 1 条评论 ·
维护者通常 1 天内回复