3 ms·
As I recall from a similar issue with Syncthing, using scoped storage for this has significant performance limitations.
by Zak 1y ago
As I recall from a similar issue with Syncthing, using scoped storage for this has significant performance limitations.
- apitman 1y agoYes and it doesn't work with native code, so you have to implement an entire filesystem abstraction using Kotlin or Java.
- izacus 1y agoThe issue with Syncthing was that the author didn't want to call out to scoped storage APIs in Java and wanted to use only Go at any cost. The performance is a bit worse but for background syncing it's not material.
- magicalhippo 1y agoNot a Java dev... How would one use the Java APIs from a Go application? I'm used to the reverse, Java calling external library.
- izacus 1y agoThe same way, just with the native side of JNI API. Usually you'd make a Java/Kotlin/Whatever class that does the JVM code (e.g. calls out to Android, retrieves the list of files, processes that and prepares the most reasonable subset of data to be passed into Go world) and then use JNI APIs to instantiate it and call it. (Alternatively, you can instantiate such a proxy class at app startup and pass it into Go world when you call into it for the first time.)
- magicalhippo 1y agoAh ok. Still, that would be a very large change to incorporate, given the current Syncthing app is just a light wrapper of the main Go application as I understand it.
- Zak 1y ago> wanted to use only Go at any cost An alternate spin on this is that a project than runs on around ten operating systems would like to maintain a common codebase for its core functionality.