This is more of a whinge than anything constructive. For all three readers who follow this blog, feel free to skip this entry unless you’re dying to find out why I haven’t made any progress on my current coding project.
Okay, it’s an application that handles persistent data: it’s my attempt at a packing list. I’ve tried a bunch of different ways to solve this problem in the past, from graph paper to spreadsheets to chalkboards and to-do list apps, even up to actual packing list applications. All of these have their pluses and minuses, and none of these is exactly the thing I want, so since I have a compiler I reckon I can build my own and beat on it until it does what I want.
So, it’s an application, because see above – the physical media approaches have drawbacks that frustrate me. Now, one of the features I really like from the other packing list apps I have looked at is this notion of categories or activities. Like, if you’re going on a ski trip, you should bring skiing stuff. So you can have a group of things that belong to that category and then, when you’re setting up your packing list, you can say, “I’m going skiing,” and the things you should have brought last time, but you forgot, but you added them to that category when you realized you wished you’d brought them, will get populated into your packing list for this trip. And if you can’t relate to that scenario, then, again, feel free to skip this post.
Anyway. There’s persistent data, and it needs to be stored somewhere. I’ve got two pretty obvious choices, here: store it in a file, which is accessible even when the Internet isn’t, or store it in a database service somewhere, which introduces a dependency on the availability of the service. That’s actually a simplification, since there are some services which have a local cache of data and allow for offline updates that eventually get reconciled when the service becomes available again, but that’s … well, it’s not the thing that’s driving me nuts right now.
A related but distinct problem is what’s driving me nuts: I have several devices which I might want to use to interact with my packing lists, and not every device is available to me at every moment, and they individually have different affordances that make me prefer using one over another for particular tasks. As a trivial example, doing lots of data entry is way more pleasant for me if I have a full keyboard and I can type away, so I like to do that sort of thing with my computer. But actually packing and ticking things off a list is much easier for me if I’ve got a handy little list that isn’t big, isn’t in the other room, and isn’t in the way when I’m not using it; so, my phone, or maybe tablet. So I want to be able to get at the current list from any of my devices.
Okay, so I could still store the data in a file and sync the file from device to device. Asked and answered, and not even that long ago. But. My experience of databases and of filesystems leads me to suspect that if device A is running process A’ and has file F open for read/write, and device B comes along and tries to copy file F over the network so that process B’ can open it for read / write, then that right there is a recipe for both processes deciding that the file is corrupt and unreadable, if the operating system, the file system, or the network stack don’t decide that first. Which means that the local file approach really needs to rely on a single writer at any moment. Realistically, that’s not the problem; the problem is the poor human who’s interacting with these devices needing to remember that part of the workflow of switching from one device to another involves closing the file to release the (implicit and possibly not always necessary, except for that one time that it is) write lock.
The way around that is to run all the changes through that previously mentioned local cache + cloud database system, and there I have a pretty clear binary choice: either go with iCloud or go with something else. The “something else” could be something obnoxious like Firebase or it could be something obnoxious like PowerSync, or it could be really obnoxious like LibP2P. And given those choices, I kind of feel like the obnoxiousness of iCloud, while significant, is not nearly so bad.
But if I go this cloud route, I’m definitely going to want to be able to take a snapshot of the whole database and dump it into a local file so that when, inevitably, the marketing department decides to make it expensive, or to share my personal data anyway, or whatever, then I’ll still be able to take my ball and go home. So why do I want to get near that marketing department in the first place? Because the cloud solution, when it does work, provides a pretty compelling value, that’s why.