Structuring libraries

[aSemy]

First, thanks for taking the initiative!

I was thinking about how to structure the project. I think Kotlinx Coroutines gives a good example of how this can be done, where there are specific support libraries for external libraries.

The question I have is, how fine-grained do the KxS support libs need to be? Is k3s-jdk okay, or should there be k3s-jdk-io, k3s-jdk-nio, k3s-jdk-sql? Both is also possible, if k3s-jdk exposes the specialised libs as API dependencies.

[Kantis]

I agree, that looks good. I think ks3-jdk is fine for starters. I don't think we'll have too big of a footprint if we go with that. We could try to limit ourselves to most useful types and add more types on demand.

[Kantis]

Are there more libraries which provide types which we want to add serializers for? Okio was a good example, where it might make sense to have a ByteString serializer in ks3-okio

[Kantis]

Should we call it ks3-jdk or ks3-jvm? I don't think we would need to have multiple variants depending on java version.

[aSemy]

I think -jdk. JDK is the toolkit, JVM is the virtual machine, plus -jvm clashes with the Kotlin multiplatform -jvm variants.

Are there more libraries which provide types which we want to add serializers for? Okio was a good example, where it might make sense to have a ByteString serializer in ks3-okio

I was thinking about adding the serializers I made for Kafka Streams https://github.com/adamko-dev/kotka-streams#kotka-streams-kotlinx-serialization

There might also be Javascript or Android types - but I couldn't find anything with an initial search.

[aSemy]

Here's another library that could have serializers: https://github.com/ionspin/kotlin-multiplatform-bignum

BigDecimal and BigInteger can't be encoded yet (awaiting the release of Kotlin/kotlinx.serialization#2041), but we could add BigDecimalAsString

[aSemy]

Currently the ks3-jdk project is set up to be Kotlin Multiplatform. However, this means it publishes -js and -native variants, which don't really make sense for this project - it's -jvm only.

Example (I've disabled Kotlin/Native locally, so there's no -native variants):

I realise now this is probably the purpose behind defining separate conventions for Kotlin Multiplatform JVM, JS, and Native!

However, what might be simpler is defining a kotlin-jvm.gradle.kts convention, and converting ks3-jdk to use this. Then the published artifact would be io.ks3:ks3-jdk:1.2.3. Pro: it doesn't have the redundant -jvm, con: it doesn't match the pattern that other ks3 libraries will have...

[Kantis]

@aSemy with the BigInteger / BigDecimal stuff I felt that it might be interesting to have format-specific modules as well..

E.g. ks3-jdk-json for the BigIntegerAsJsonLiteral / BigDecimalAsJsonLiteral serializers (which us JsonUnquotedValue for JSON and regular String for other formats) There's not really any reason to use this unless you're working with JSON

[aSemy]

I think that makes sense, but I'd be a bit cautious about fragmenting the subprojects too much.

A ks3-json subproject makes sense, and if you make it multiplatform then the BigDecimal serializers would go into ks3-json/src/jvmMain, which would then be published as ks3-json-jvm.