Things need to be done in 0.1.5

[4t145]

Features:

• Easy-to-use sse server transport type 封装 SSE 的服务层设计，让应用层开发更简单 #27

Bugs:

• Incompatibilities with python SDK and Js/Ts SDK Intergration tests with Python and JavaScript/TypeScript #32 typescript-sdk 调用 listTools 出错 #31
• new SSE implementation bugs The new sse client implementation breaks connections to servers built with the Python SDK. #26

Documents:

• Websocket transport example Websocket transport layer. #28

[jokemanfire]

Is there any default that needs to be done here? I want it to stabilize and then apply it to my project.

[4t145]

Is there any default that needs to be done here? I want it to stabilize and then apply it to my project.

What do you mean when you say any default? 我觉得我们其实也可以讲中文。

I don't have any idea about new features by now. I wish you can apply it to your project firstly and then we may find out something we forgot to do.

[jokemanfire]

Because in order to encourage more participants to participate, there will be a barrier in Chinese, although it is good for us to communicate.
I have this question because the annotated items do not clearly state the remaining tasks to be done.（因为标注的事项没有明确写剩余要做的事情，所以有这个疑问。)

[byeblack]

I have a few preliminary suggestions that might help improve this project:

1. Gradually stabilize the API to make it simple and easy to understand;
2. Identify and address incompatibilities between current functionality and the official SDK (I've noticed that with complex types, rmcp client can call self-built servers but fails to call servers built with the Python SDK - I'm still investigating the cause);
3. Support more transport options (e.g., WebSocket);
4. Add support for WASM/WASI (I attempted to apply it to the wasm32-wasip2 target, but had to abandon the effort due to Tokio's limited support for wasm32-wasip2, such as HTTP, async stdio, etc.).
5. Dynamic tools (maybe I need it)

[4t145]

@byeblack
For API, I think the main jobs have been done. We could add more helper methods, without bringing in breaking changes.

For transport, there's no standart here beside the SSE and stdio. But we can add an example with tokio-tungstenite.

For compatibilities with Python SDK, this is important. And I also want to help to solve these problem, could you post a issue on this bug?

For wasip2 target, we can implement AsyncRead and AsyncWrite for the wasip2 io. I've tried but it seems like main thread blocked somewhere. I also put WASI compatibility at a high priority.

[byeblack]

@4t145 Thanks for your reply

For wasip2 target, I also implemented a simple AsyncRead and AsyncWrite, and tried to verify it with wasmtime, but stdout was blocked at the start of the second response, but stdin still worked normally...

6. There is also support for dynamic tools (maybe I need it)

[4t145]

@byeblack
我认为动态工具调用其实某种意义上已经实现了？因为工具调用的api本来就是渐进式的，首先，你可以直接在实现tool_call的时候去手动分发，其次，就算通过toolbox分发，toolbox里面存的内容也是Dynamic Trait Object。只是我们使用宏的时候，生成的东西都是静态的。

I think dynamic tool calling has been implemented in a sense? Because the tool calling API is inherently progressive. First, you can manually distribute it when implementing tool_call. Second, even if it is distributed through toolbox, the content stored in toolbox is also Dynamic Trait Object. It's just that when we use macros, the generated things are all static.

也许文档没有很清晰的说明这一点，我们应该在文档里说明清楚。

Maybe the documentation doesn't explain this clearly, we should explain it clearly in the documentation.

[jokemanfire]

I think WebSocket transport can be used as a puncture replacement for SSE. Although the official discussion did not use WebSocket, we can consider designing it.
Pr disscussion

[4t145]

@jokemanfire Wow, that pr has a similay idea with mine in https://github.com/4t145/rmcp/blob/dev/examples/transport/src/http_upgrade.rs