Don't you know that serfs living in digital fiefdoms don't have rights? They're living on the lord's property and the lord's property rights must be respected above all else.
This seems like a particularly egregious aspect of a larger problem; that we allow medical advertising at all. From what I understand some of European countries don't allow advertising for legitimate medicines, let alone snakeoil. That makes a lot of sense to me; the ads for legitimate medicines all seem emotionally manipulative; designed to make people pressure their doctors into writing subscriptions they might not actually need. If facebook adopted a strict "no medicine" policy, they wouldn't have to sort the wheat from the chaff.
Sometimes a programmer may like to create such a contract, if only with their future self, but have reason to fear their boss will force them to break that contract in some not unlikely future.
Adobe Lightroom seems comparable (non-destructive image editing.) It uses a sqlite database that points to image files on the filesystem. I think precisely the same approach could be taken with an audio editing application.
You could also consider putting the audio files into the sqlite db, which might work alright. I've heard of image thumbnails being stored in sqlite dbs (maybe by Lightroom iirc?) though those are probably smaller than your audio clips I'm guessing.
I think the former is preferable and most modern users will prefer it. However if your users are upset about it, you could do the later, or you could do the former and give them a dummy/placebo "save" option that does nothing, or maybe VACUUMs the DB.
> it also makes the saving process itself more fragile (since the longer a save takes, the more likely it becomes that the process might be killed by some natural event like a power cut during it†.)
This is one I take very seriously, after I got bit by it. I was saving state by writing s-expressions to a text file; it seemed a reasonable enough thing to do even with tens of megabytes of it, until my laptop turned off in the middle of a write. After recovering from a backup and losing several hours of work in the process, I switched to SQLite that evening.
> Main reason for existence of lot of file formats is that enterprises don't want just about everyone access their files and modifying them. It greatly reduces the usage of their proprietary software hence their revenues.
I'm sure this does happen, but it seems more like MBA-paranoia than a legitimate concern. For instance I sincerely doubt Adobe has lost any revenue by using SQLite with lightroom, despite various open source tools being able to interact with their lrcat (sqlite) files.
Is there any good way to use SQLite as an application file format while also using it in WAL mode? They seem sort of mutually exclusive; near as I can figure the way to do this would be to execute `PRAGMA journal_mode=DELETE` when the user requests a save file, then copy the DB to the location the user specifies. I think this negates a few of the advantages of using sqlite as an application file format though.
Amazon will knock $20 off the price of a kindle if you get the version with ads. And those only display static grayscale ads, advertisers may be willing to pay more for something more invasive. Extracting $25 of value from spyware on televisions doesn't seem out of the question.
An HOA is the last sort of organization I'd trust to run a firewall for me. Those orgs are magnets for petty tyrants, bored stay-at-home control freaks who want to flex on the neighborhood. How many would decide to turn the internet off after 8pm "for the children" or something equally inane?