Published a new log on building Linkora's "web-capture" feature handling Rust, JNI, file descriptors, and coroutine cancellations:
https://t.co/mZ47VR6gY5
I've published a new write-up on how @LinkoraApp handles OTA localization without pulling in third-party SDKs.
https://t.co/9UwYh5ZuHe
Skip directly to the good part:
https://t.co/6FcDbKrZon
i've forked monolith to support _cancellation_. native interop is fun.
handling JNI exceptions isn't fun, ended up using SAM conversions for callbacks instead of dealing with JNI
Published a new log on building Linkora's "web-capture" feature handling Rust, JNI, file descriptors, and coroutine cancellations:
https://t.co/mZ47VR6gY5
@code_bytein v7 is ofc much better if exposing primary key isn't sensitive, even then i guess a secondary v4 that gets exposed to clients should do it with a separate index for lookups or maybe some sort of cache, which "defeats" the purpose of v7.
@LinkoraApp@LimaeApp I could package the entire object as a collection instead and get rid of every specific operation, which would make the codebase much easier to maintain, but it might increase bandwidth usage. So, that's that. 9/9
Rewriting syncing mechanics in @LinkoraApp. Been experimenting around CRDTs and they shine when dealing with collections of items that need to be merged. Martin Kleppmann has great explanations on this (which I'll use for @LimaeApp in future). 1/9
@LinkoraApp@LimaeApp I might still need specific operations like edit title, note, or parent rather than naturally merging two edits the CRDT way. Especially if the update is happening post operation. 8/9
v0.16.0 of @LinkoraApp makes imports/exports a lot more efficient. Both now run in O(n) instead of O(n^2).
JSON imports: 56.1% less heap memory, 17% better CPU efficiency. HTML imports: 58.7% less heap memory, that's ~225MB less. (1/4)
Pagination is now cursor-based instead of offset-based. Sliding window is still there (was before too), using Kotlin Flows to keep only viewport items in read connections. (3/4)