Ktor IO dependency should be an `api` dependency about kommand

[BppleMan]

Now, we can migrate to kotlinx-io
https://youtrack.jetbrains.com/issue/KTOR-6030/Migrate-to-new-kotlinx.io-library

[BppleMan]

You're right, but I'm considering whether to use okio, which is a standalone io library that might be easier for users to learn. If I'm not going to expose any 3rd party io, maybe I really need fully encapsulated io. Do you have more views on this?

[Jeffset]

Thanks for the reply! I think, fully incapsulating IO is a great idea, go with it if you can. This way you can decide on what actual IO backend to use and update without introducing breaking changes for the clients.

[BppleMan]

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

[BppleMan]

Anyone can discuss below

[sanyavertolet]

In our projects we use square/okio which is nice (has 8k stars). At least, it seems more popular, so it might be better to use it, nevertheless, I'm not sure it fits you

[BppleMan]

In our projects we use square/okio which is nice (has 8k stars). At least, it seems more popular, so it might be better to use it, nevertheless, I'm not sure it fits you

Using okio I think is acceptable, But more votes are needed

[BppleMan]

this is a poll
#8

[sanyavertolet]

Any updates here?

[BppleMan]

In fact, the current approach is a simple io encapsulation, and the exposed APIs are readLine and lines.

kommand/src/commonMain/kotlin/com/kgit2/io/Reader.kt

Lines 12 to 37 in f26c061

	open class Reader (
	private val platformReader: PlatformReader
	) : Input(
	// pool = DefaultBufferPool(Buffer.ReservedSize + 1, 1)
	) {
	override fun closeSource() {
	platformReader.closeSource()
	}
	override fun fill(destination: Memory, offset: Int, length: Int): Int {
	return platformReader.fill(destination, offset, length)
	}
	fun readLine(): String? {
	return readUTF8Line()
	}
	fun lines(): Sequence<String> {
	return sequence {
	while (endOfInput.not()) {
	readUTF8Line()?.let { yield(it) }
	}
	}
	}
	}

ktor-io only acts as a middle layer. It neither makes real system calls nor uses its external API. It only acts as a buffer to assist the above API.

Therefore no changes will be made for now, the api is simple enough to provide full functionality