Store
Store copied to clipboard
[Feature Request] Multiplatform support
Is your feature request related to a problem? Please describe. It would be nice to migrate the project to support multiplatform projects in the future
Describe the solution you'd like Multiplatform projects with native or js targets could possibly make use of the Store functionality. The possible implications:
- A more stricter multiplatform persistence library support for multiplatform projects (SQLDelight)
- Other possible jvm dependency changes & abstractions, like Date & Time
- Current K/N concurrency model restrictions related changes
- New abstractions, native interoperability considerations may also introduce changes
Additional context Since Store is a library for the data layer, which is the primary target for multiplatform projects, I believe it would make sense to move in a platform agnostic direction by covering more kotlin targets (However it might make sense to review the JVM and/or Android dependencies more closely)
PS: I'm more then happy to contribute in any format, so let me know if you need any kind of help
Hello! Thank you for the feature request. We've always wanted store to be multiplatform friendly but don't think we can achieve it yet due to our reliance on actors which are currently incompatible with kotlin multiplatform. As kmp matures and adds support for multi threaded coroutines we would definitely want to stop targeting Java only.
I would also contribute to this if/when it takes place. Absolutely love the store API for modular kmm application; currently have it working with no cache layer (yet) and a modified actor for kmp.
Would love to see your impl. If there is a clean way to separate the jvm parts out I don't see any reason not to go kmp.
I stole the code snippet here : https://discuss.kotlinlang.org/t/actor-kotlin-common/19569 and replaced the call to jvm actor with this one in StoreRealActor and then ripped out the cache layer. As this was all PoC work I only tested it in an Android application since we're targeting Android first and iOS in the future.
Testing on iOS and reimplementing the cache API with a cross platform alternative is on the road map but I had to punt it down the road.
cc @ychescale9 who has a kotlin version of the cached. Hmm this is looking more possible everyday
Probably too late for 1.0 but does it make sense to make our cache implementation pluggable?
Yup should be reasonable for 1.1
Past few days I've worked on migrating testing over to multiplatform. Had to trade Truth for Turbine to implement the .emitsExactly
testing tool. Additionally, I've had to migrate the TestCoroutineScope to multiplatform (as coroutine-test is not a multiplatform library). So far, everything is passing in jvm and iosX64 but it is sans cache layer. I've commented out tests with .cache
requests which means quite a bit of functionality is not covered. Additionally, I swapped the implementation out in the sample and it works as expected.
I did everything in a different module so that I could reference the original, however. If you're interested in it I'd be happy to submit a PR. I've kept a running list of changes since it's done in a different module; or I would be happy to move the code into the store4 module for better diffs.
@ychescale9 mind linking to your cache impl?
Would love to see your changes as well. This makes me feel like we can make it work sooner than I thought
It's not quite ready yet. I setup the KMP project and ported some tests but haven't done much work since.
I'm hoping to get back to it over Christmas. Will share it as soon as I have a working prototype.
KMP port of my original kotlin/jvm cache: https://github.com/ReactiveCircus/cache4k
A few notes:
- currently supports jvm, ios, macos, js, but I haven't tested in a real app other than running the tests on those platforms
- implementation is powered by Stately's
IsolateState
andAtomicReference
- this is probably not 100% thread-safe as there's no synchronization of those 3 collections (will need to learn how to do it without using a
Lock
in all operations) - haven't done any benchmarking (I know perf is not great at the moment)
Hi guys, can I please ask if this is on the roadmap?
Our internals are built expecting multi threaded coroutines. Once kmp coroutines support access across threads, we will begin working toward compatibility. It's unclear when that will be the case
kotlinx.coroutines
has a native-mt
artifact for experimental native multithreading. Ktor has been using it for some time.
It's on the radar but after the breaking changes in duration experimental apis, we are being more cautious with depending on experimental branches
Any updates on this?
The new MM will be merged into the main branch in coroutines 1.6.0. As it's explained in this issue, isExperimentalMM
will be used to know if you can use multi-threading or not. From my point of view, there's no blocker to support multiplatform, because the user can select if the multithreading mode will be used or not. It will be merged into the main branch, so you will not depend on an "experimental branch" What do you think @digitalbuddha? Are you planning to implement it? do you have an estimated time?
Planning to yes but no estimate. We are starting to explore kotlin native. Any help would be appreciated. See @handstandsam
When we do approach we should pull this back in https://github.com/ReactiveCircus/cache4k
After the new memory model release i searched something to try it . so i started to convert store4 to kmp some weeks ago. I removed everything from the guava cache , but kept the implementation , so it only supports strong references and no loader atm. For this i added just a simple 'getOrPut' as a replacement for now. Thread safety was achieved using kotlinx-atomicfu. Also the code could be more kotlin-ish. During a quick performance test it is very close to the original implementation.
So i "finished" converting : cache, filesystem, store and multicast to Android/iOS/JVM Anyway, still a lot of sample , tests, cleanup work.
I forked Store4 but working in a private repro atm.
Wow sounds awesome! We can make a branch here if you’d like play in the main repo. Excited to see progress
Sure thing. But i created a new project and added module by module as it was too time consuming for me to get the current gradle script working as kmp. If this is not a problem, i can push a wip version this weekend i guess.
@digitalbuddha In case u wanna take a look , i pushed my current progress here https://github.com/aclassen/Store
Looks awesome! I created a branch Kmp in case you want to start integrating back into the main repo. I’m excited for the shape this is taking
Hello everyone ! I want to participate this project, please allow me join this project
Hi folks hold tight, there will be some messaging from dropbox coming along with how to join the google summer of code projects
Hello everyone, I'm Kaustubh Chavan, a third year computer engineering student and a GSOC aspirant. I came across this project yesterday and found it fascinating. I have some experience in java language and really passionate about my field. I'm really interested in this project and want to be a part of it and help develop the software.
Regarding Google Summer of Code (GSOC), this project is unfortunately no longer going to be participating.
@changusmc sent out this message regarding it: https://twitter.com/changusmc/status/1509231084638142467
Due to some personnel transitions, Dropbox unfortunately had to pull Store from #GSOC2022.
We sincerely apologize for the inconvenience.
Just another nudge; would love using this in our multiplatform project.
Hey all - Store now targets Android, iOS, JVM, and JS!