使用tonic实现RPC #375
使用tonic实现RPC #375
Conversation
Web 不一定需要 RESTful API，web 可以走 grpc-web，然后 tonic 可以通过 tonic-web 来提供对 grpc-web 的支持。这样的方案比较成熟。 |
那好，我会把这个的优先级延后。 |
| let mut buff: Vec<u8> = Vec::with_capacity(buff_size); | ||
| let data_size = self | ||
| .get_uuid(buff.as_mut_slice(), buff_size as u64) | ||
| .unwrap(); |
There was a problem hiding this comment.
这里不应该 unwrap, 如果是 null_size 就会返回 Err。我觉得使用 Device ID 来当 Session ID 可能不是很合适，在 macOS 上这个返回的不是一个 UUID，相反这个 ID 永远都是一样的。我觉得还是自己生成一个 UUID5 比较合适。
There was a problem hiding this comment.
这里我参考的是 主仓库的代码，没有考虑到可能存在错误的情况。
如果在macos上uuid为一常量，那么日志追踪就不可能完成，因为无法区分callback的来源（目前是通过解析msg中的uuid来追踪的），由此导致状态更新也不可用。
不过MaaCore也提供了custom_arg以提供额外的追踪参数，或许可以依赖这个来追踪
总之，我会将这个error作为uuid获取失败传递到client端（虽然这不太可能发生）。至于更新Session ID，我会在目前写完状态池后去做。
There was a problem hiding this comment.
我刚刚合并了一个 #376，你可以 merge 进来用那个版本的 get_uuid。
关于状态池目前的处理是subtask对应的变更直接保存，以便客户端“复原”执行过程 事实上我在考虑合并日志池和状态池，因为他们的功能相近（至少目前如此） |
Close #322
Todo
track_id(session_id)生成方式（使用uuid_v7）load_core中（目前是在state目录下创建下级文件夹，e.g. ~/.local/state/maa/test）提供RESTful api需要讨论的部分
提供RESTful api
目前有三种方案
使用
axum接受json，转换为protobuf后转发给tonic好处是可以选择是否开启http端口及其服务，坏处是需要手动编写路由及转发（可以考虑展开宏？），还有一定的性能损失（无伤大雅）
修改
tonic-build，使tonic可以自动根据传入的content-type切换codec好处是无需额外代码，坏处是需要使用自定义的tonic-build库（crate.io-patch）（至少在我想办法把它合并到tonic官方库前），以及只能监听一个端口，要么本地socket，要么http端口
构造一个tower中间件，将传入的
content-type为json的请求从json转换为protobuf不用重新路由，不必修改tonic-build，但只能监听一个端口且有性能损失
合并部分cli功能
todo
Notice
这是在 #374 的基础上编写的，所以请忽略其对
maa-cli的修改