-
-
Notifications
You must be signed in to change notification settings - Fork 15
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
Update deps and migrate from okio to kotlinx.io #112
Conversation
Temp repo: maven {
name = "worldmandiaRepositoryReleases"
url = uri("https://repo.worldmandia.cc/releases")
} implementation("io.github.xxfast:kstore:0.8.0") |
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 very much for the contribution 🙇
import kotlinx.serialization.Serializable | ||
import kotlinx.serialization.SerializationStrategy | ||
|
||
public abstract class KStoreFormat<T : @Serializable Any>(public val serializer: KSerializer<T>) { |
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.
Is there a reason why we need this intermediary class instead of passing in the serialiser directly?
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.
Not all formats support KotlinX.IO
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.
Hello.
It would be premature to support custom serializers, becouse kotlinx.serialization is currently stable with only the Json serializer.
It may be possible to use a protocolbuffers/protobuf serializer like Jetpack DataStore, but is that level of customizability necessary?
In any case, support for custom serializers is not important when migrating from Okio to kotlinx.io, so this should be considered in a new pull request.
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.
as before you do not need to change this, since there is a JSON serializer, this is simply done if you really need to change this, kotlinx.io allows you to convert this to java bytearray and/or string
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.
as before you do not need to change this, since there is a JSON serializer,
I see there are no breaking updates on this.
I see there are no breaking updates on this, except for argument name changes such as kstore.file.storeOf.
this is simply done if you really need to change this, kotlinx.io allows you to convert this to java bytearray and/or string
I don't see any reason to bother writing your own EncodeToSink to encode to a Java ByteArray and/or String. Wouldn't Json encoding be enough?
For large datasets, ProtoBuf is a good choice, but as I mentioned in the previous comment, kotlinx.serialization's ProtoBuf is not stable. Google's protocolbuffers/protobuf is stable but only supports the JVM.
It should remain simple and tiny without adding unnecessary customizability, I think.
In any case, support for custom serializers is not important when migrating from Okio to kotlinx.io, so this should be considered in a new pull request.
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.
Yeah prolly best if we do this separately - and I agree we would need some abstraction to handle multiple formats, but we will cross that bridge when we get there
Looks like CI is failing
I will fix these in my branch |
kotlinx-serialization = "1.6.2" | ||
okio = "3.9.0" | ||
junit-jupiter="5.10.1" | ||
kotlin = "2.0.20-Beta2" |
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.
Hi @mani1232 is there a reason why we can't use the latest stable?
Included in #116 and available on 0.9.0-SNAPSHOT |
No description provided.