-
Notifications
You must be signed in to change notification settings - Fork 176
Remove dependency on CIO engine #223
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
Conversation
|
Thanks @MukjepScarlet for your pr! Sorry, I’m having trouble understanding the motivation behind this PR Also, the user can already choose any other engine. CIO is just the default engine |
|
The main motivation is that the users of client applications like iOS/Android/Desktop would like to see a smaller package. And we usually want to integrate the lib into an existing application with some infrastructures, maybe tons of configurations, in this situation the lib-integrated engine is redundant. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, @MukjepScarlet
It's totally make sense to remove Ktor engine implementations from library dependencies, so users would not have to exclude CIO if they want to use another client or server. Let's mention it in the documentation/README too: now users have to explicitly provide KTor engine dependency in their application.
|
Waiting for test workflow |
replace with core
replace with core
- Add runtime dependencies to CIO server/client in samples - Update README.md about adding Ktor engine dependencies - Add test runtime dependency to slf4j-simple
devcrocod
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Replace the CIO dependency with only server/client core dependency.
Motivation and Context
In order to minimize the size of package. There are probably other existing engines like Netty/Tomcat(server) or Java/OkHttp/Apache(client) in the classpath. So we can reuse existing infrastructure.
How Has This Been Tested?
I have run:
buildof samplesI have an issue about
samples/kotlin-mcp-server.io.modelcontextprotocolis not found incommonMain.Breaking Changes
Yes. They need to
implementationCIO engine manually if they use it in their app.Types of changes
Checklist
Additional context
closes #111