A realisation:

When an 'application' is no longer 'a piece of code on your computer that you may or may not have the source code to', but 'code and data running on someone else's computer that might even be in a different country'...

... suddenly the argument about 'should data be owned by applications for safety, or should it be owned by the operating system for interoperability' becomes no longer academic.

If data is owned by 'applications', it's not owned by YOU. It's not on YOUR computer.

The realisation is that this is why I get so. damn. grumpy. about applications acting like petty little feudal dictators about data... and grumpy about the programming 'best practices' (like databases being so very closely linked to specific applications) that enable this.

It's MY DATA. Get it the HECK out of YOUR application. I want it on MY COMPUTER.

That means I need somewhere to put data that's not application-centric..

And we don't have many places for that. The filesystem and, um...

... THEORETICALLY, a database server, but in practice? Yeah, right. Nope.

Databases exist for the purpose of denying access to data.

This is fine until you find yourself on the wrong side of a database and it's your data.

Essentially, a database is its own little OS, with its own little list of users and passwords, which is... silly if you already have an OS, which we do, and worse than silly when you realise that many applications use databases as a way to move data out of your computer, and put it on someone else's. And if it *is* on your computer, it's often still locked to a service account used by the app. *You* don't get to access it. You don't rate high enough. The Computer outranks you.

The other super annoying thing about databases is that they're not (generally) recursively structured.

Filesystems are recursively structured. Dictionaries and objects (ie, JSON, or all the stuff in RAM inside a C++ or Java program) are recursively structured.

You can't put a (SQL) database table inside another database table. Everything's one flat namespace (maybe three levels: Server, Database and Table) and inside that, everything has to be rigidly the same data shape.

Filesystems are pretty good at copying data. (Modulo problems crossing filesystem boundaries, as I found yesterday). You just... put a folder in another folder and you're good.

But you can't do that with a database. Getting data in and out for backups or just moving it around is a royal pain. It's not a one-step process and it's just not much fun.

I guess what I'm saying is maybe a NoSQL database of some kind (strictly only one per OS, with per-object permissions) might be the future.

Failing that, I guess we'll still have thngs like SQLite... lots of different binary db files that at least can be copied when the application is shut down (unless it has a service and you're never sure when it's shut down)... but it's still really annoying trying to mix and match data between different apps, which is fundamentally what I'd like to do.

The file/document/folder metaphor still seems good for 'data at rest'. But data that might change rapidly? I dunno. I just want to... link to it