As a four year old, my child loved playing "the subway game", which is similar to this but just in our heads: I name two subway stations and he tries to think of the fastest route between them. When that is exhausted, we move onto the fewest transfers, the most convoluted routes, the 1968 lines only, etc. There's just something about the NYC subway which really draws kids (and many adults) in.
We tried this out a middle schoolers at an installfest in Alabama in the 90s, but something was broken with the resulting install and had to wipe it and start over. Funny that 25+ years later I learn that the problem could have been that the locale was set to en_RN…
You can even do neat things like having the revalidate fetch tell your backend “I served this object out of cache 1100 times since last fetch, maybe consider putting a few extra cpu cycles into the compression on this one”
Looks interesting, I'm curious how you settled on WebDAV? A decade ago I built a NextCloud alternative backend that also used WebDAV, and I'm not sure it's something I would ever touch again. Lots of clients say they support WebDAV but they all do slightly different things, and if you own the clients then there are probably simpler protocols.
The desktop app uses WebDAV for the sync (via rclone) just because it was the simplest and most reliable way, but the listing of directories (to choose sync) and the mobile app use a simple HTTP API.
Yes, there are a bunch of redis+disk projects out there, one big consideration is the size of your values: some must hold all keys in memory and only offload values to disk, while others (kvrocks, other rocksdb dbs) can offload both keys and values to disk, with some other tradeoffs.
I’ve been testing kvrocks as a replacement for a Scylla use case where we have TBs of data and uniform TTLs. In many of these LSM dbs, compaction is the thing that really kills throughput, making TTLs (or really any updates/deletes) difficult.
KVRocks doesn’t expose it directly right now so it requires code changes, but so far I have had good success with FIFO compaction. When an sstable gets old enough, it just gets dropped.
I had a similar experience: I built dragging and handle resize, then later added rotation via a bit of trigonometry. Each operation worked fine separately, but if you tried to rotate and then resize, unexpected things happened. I left the bug for years, thinking I needed to come back and just add a bit more trigonometry to get rotated resizing working. When I finally came back to it I spent quite a while hacking at it before realizing that matrices were a much better way to describe the solution.
Using jQuery CDN might have helped with cross-site caching in the past, but now all major browsers have cache partitioning by origin for privacy reasons.
On Mobile Safari at least, you can press and hold the image to share. I imagine there's probably an equivalent gesture on Mobile Chrome. I spent considerable time many years ago trying to figure out how to indicate to users that they could do this. ("press and hold to share", with a progress indicator) Results were mixed.
Fortunately, these days if you wanted to make it more obvious you could hook up a regular Share button to navigator.share() API and pass it your image blob.
