-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move the SseResponseStreamTransport out of sample #47
Move the SseResponseStreamTransport out of sample #47
Conversation
src/ModelContextProtocol/Protocol/Transport/SseResponseStreamTransport.cs
Show resolved
Hide resolved
src/ModelContextProtocol/Protocol/Transport/SseResponseStreamTransport.cs
Show resolved
Hide resolved
Where is this being done? |
src/ModelContextProtocol/Protocol/Transport/SseResponseStreamTransport.cs
Outdated
Show resolved
Hide resolved
I assume it's where HttpListenerSseServerTransport delegates SendMessageAsync to HttpListenerServerProvider which will :
This could be provided by the shared SseResponseStreamTransport. HttpListenerServerProvider could have been folded directly into HttpListenerSseServerTransport (when it was changed from an implementation of an injected provider to a utility class). Using SseResponseStreamTransport would make it possible to do without HttpListenerServerProvider becoming bloated, so it's sounds like a good improvement to me. |
I added a commit to this PR. |
Ok, cool, so I wasn't going crazy :-) Thanks. |
TODO:
Add loggingI decided against adding logging since logging could be added by the creator of the transport like the ASP.NET Core sample or the HttpListenerSseServerTransport as demonstrated by this PR.Use it in the HttpListenerSseServerTransportDoneI'm working on these things now, but if we like the API shape, I think we can merge it as-is to let people try it out and do the TODOs as follow ups.