用户建议 Q&A（产品能力与配置体验）

本文整理用户关于“复杂解析扩展能力”和“配置管理方式”的典型建议与官方答复。

Q1：复杂数据结构解析，是否支持可选 Python/JS 脚本扩展？

A： 我们理解并认可这个建议的价值。Python/JS 普及度高，上手成本低，这是事实。

但 WarpParse 当前主路径仍以 WPL/OML 为核心，主要原因有三点：

1. 语义更聚焦：WPL/OML 的目标是用更直接的语义描述“提取什么、转换什么”，而不是通用编程流程。
2. 复杂日志仍可简洁表达：在我们已接入的复杂日志场景里，WPL 规则通常比通用脚本更短、更易维护。
3. 性能目标约束：在 Rust 主链路内引入 Python/JS 运行时会带来额外开销，不利于高吞吐、低延迟目标。

我们会持续降低 WPL 使用门槛：

• 通过 WpEditor 可视化 IDE 降低编写与调试成本；
• 通过 AI + Skills 自动生成/优化 WPL；
• 对复杂日志提供官方解析支持（规则建议、示例、定位与优化）。

Q2：连接信息是否可以统一管理，并按唯一名字引用？

A： 认可并支持该方向。建议将 MySQL、Kafka 等连接信息集中管理，业务配置只引用连接名（如 mysql_center、kafka_log_cluster），避免在 source/sink 中重复写 endpoint、账号、密码。

这样可以获得：

• 更好的安全性（敏感信息与业务配置分离）；
• 更低的变更成本（地址/凭据变更时只改一处）；
• 更清晰的治理能力（统一命名、统一审计、统一轮换）。

Q3：当前一条链路要改 source/sink/wpl/oml 多处配置，是否可以合并？

A： 这个反馈准确：在简单场景下，多处分离配置确实不够方便，容易漏配或配错。

当前分离配置的设计初衷是面向长期运行与规模化治理：

• 分离维护责任；
• 提升规则与连接器复用能力；
• 建立可审计的配置变更机制，降低线上风险。

针对易用性，我们的改进方向是：

1. 提供更完整的一体化配置示例，降低首次接入成本；
2. 后续提供可视化界面管理版本，减少手工维护多处配置的负担。

我们会持续在“简单场景易用性”和“复杂场景可治理性”之间做平衡。