You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been thinking about this issue recently. Now kotlin-multiplatform does not have a standard io protocol or implementation. Although ktor-io belongs to the first-party library, it is not in the stdlib, which creates a problem. If every third-party library Providing your own set of io standards is very unfriendly to users. Every time users use a library, they need to learn the io api corresponding to the library. This is really ugly, so I considered using ktor-io at the beginning. But before kotlin officially proposes any standard library implementation, I don't think more io implementations should be added, which is meaningless work.
But custom io api is not undesirable, at least it will be more controllable for project maintainers. While it might not have many complex features, it at least keeps it minimal.
Which I/O should be selected
ktor-io(first-party library, maintained by ktor, but not perfect)
0%
okio(active maintenance, but third party)
75%
kommand-io(custom api, more controllable, but also increases maintenance workload, and some uncertainties)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have been thinking about this issue recently. Now kotlin-multiplatform does not have a standard io protocol or implementation. Although ktor-io belongs to the first-party library, it is not in the stdlib, which creates a problem. If every third-party library Providing your own set of io standards is very unfriendly to users. Every time users use a library, they need to learn the io api corresponding to the library. This is really ugly, so I considered using ktor-io at the beginning. But before kotlin officially proposes any standard library implementation, I don't think more io implementations should be added, which is meaningless work.
But custom io api is not undesirable, at least it will be more controllable for project maintainers. While it might not have many complex features, it at least keeps it minimal.
4 votes ·
Beta Was this translation helpful? Give feedback.
All reactions