A month on, and my little program to suck up and display the podcasts I have listen ed to is working well, but not perfectly. It still sometimes duplicates an entry it has already created, and I have been having a difficult time trying to work out why.
One simple reason for the difficulty is that I do not want to hammer Overcast with requests for my detailed OPML file. There's a rate limit on requests. I have no idea what the limit is, but I do not want to reach it. So, when I think I might have solved the problem, on stored data, I have to wait a day or so to try it against the live data. Occasionally I think I've cracked it, and then it breaks again, and the honest truth is that I have not been able to pin the source of the breakage down to my code or the OPML file I receive.
I've tried working on the stored data to see whether I can narrow the problem down, and that's great, as far as it goes. But, as I said, I have to wait until I've listen ed to another couple of podcasts before I can try it again for real, which makes for slow going.
The difficulty seems to be that Overcast stores whether I have deleted the episode, whether listening is in progress and whether it has been played, each as separate key:value pairs. I don't want things that have been deleted unlisten ed and I don't want things that are still in progress. I only want things that have been played, no matter whether they have been deleted meanwhile. The logic for that is proving trickier than I expected.
Right now, I run the program manually, check for problems and then push the new posts out there. I won't be able to automate it until it has been working perfectly for a week or two, which may be never.
A side effect of all this has been that I have not devoted much time to any other sort of writing here. It being Friday afternoon, maybe I'll spend the rest of it rectifying that.
Webmentions allow conversations across the web, based on a web standard. They are a powerful building block for the decentralized social web.