Wednesday November 3, 2021; 11:53 PM EDT
- I've had a few minutes to think about what I described earlier, and after congratulating myself on how awesome I am (try it sometime), I looked for the stupid parts. (Try it sometime.)#
- The main stupid part is that, as described, building the blog will take longer and longer, simply because the list of posts grows and grows, and so does the list of categories. Even if I didn't make any changes to any of the tags on any of the posts, every time I push my blog to Old School, my little script will walk a LOT of nodes, and walk them over and over.#
- There are a bunch of ways to fix this, and we can use any or all of them. #
- Add a flag to the post's tags node that says "we totally already did this"#
- Do the update just once instead of updating tags.opml for each tag we find#
- While walking blog.opml #
- Build a collection of nodes that are going to need to be updated, the gfaType=tag nodes#
- Do we need to keep a reference to where we found the node so we can go back and update it for some reason?#
- Can I even navigate opml like that, with like a gid for a node? That would be pretty sweet but #
- It could cause the destruction of the universe#
- It's highly unlikely anybody would build such a thing for the purpose of manipulating opml files in JavaScript #
- Seriously it's a tree, why would you build an index into a tree (hehehe)#
- Collection should be a set uniqued on the intersection of metadata (ok just the thing I haven't named yet, the cleaned-up-for-url version of the tag)#
- Then go off and update tags.opml, hopefully they're sorted similar if you have a lot.#
- If tags.opml is sorted different than the collection you built and there are a shit ton (term of art) you'll want a mapping from one collection to the other (nobody would ever really need this)#
- Only do the update when it needs to be updated#
- This can be harder than it sounds if you want it to happen automatically#
- But I am the complete master of this machine I am building, so I know when the tags on a post get created or updated.#
- So, give up on the entire "let's walk the tree to find tag nodes and blah blah" and make a new button that, well, walks the current blog post looking for tag nodes, and blah blah... but it only has to look at the post I'm working on, and it only runs that single time.#
- Which means the latency between my clicking the cloud-up-arrow button and being able to view the results in a browser will stay as low as I can get it. And I don't have to build some insane cache invalidation system like I totally plan to some day for perfectly valid reasons that aren't insane at all. #
- (Why would you build an index into a tree?)#