💾 Archived View for gemini.circumlunar.space › users › solderpunk › gemlog › unification-progress.gm… captured on 2022-07-16 at 13:30:49. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Unification progress

I'm making good progress on unifying my Gemini presence, as discussed previously:

Identity Crisis

All the posts in my three previous gemlogs have now been copied across to my single new gemlog, and there should be redirects in place that sending you from the old URLs to the new URLs. This means links people posted in places before the transition should still work. If you encounter any broken links, please let me know! The new gemlog has a link at the top of its landing page to a short explanation of the change. The landing pages of the old gemlogs are still in place at their old URLs for historical interest, but have clear discontinuation notices at the top. Later today I will pull the old feeds off of CAPCOM and replace them with the new feed. Anybody who subsribed to the old feeds and isn't watching CAPCOM might miss the change, but that has to be an extremely small audience. A quick grep of the Molly Brown access log for gemini.circumlunar.space suggests that those individual feeds get hit extremely infrequently, perhaps just by bots.

There have been a few hiccups along the way, already, but they're good hiccups in the long run: my basic Gemini tools are getting battle-tested via solving real world problems, of the kind which are likely to happen for other people.

First of all, while using `.molly` files to set up the redirects, I stumbled across a bug in Molly Brown where configuration options specified in said files were being applied more widely than they should (i.e for URLs not in or below the directory containing the file), and were persisting even after the file was deleted. That was surprising, and kind of scary! If you're running Molly Brown in a multi-user environment and have activated support for `.molly` files, you should definite update.

This bug happened because I'm still pretty much a beginner at Go. I wrote the code to override the main configuration settings with directory-specific ones with the idea in my head that "Go is a pass-by-value language", and hence any changes made within one function would not be visible outside of that function. It's true that Go is pass-by-value, however the "value" of certain variables - including maps, which are used to implement redirects and certificate zones in Molly Brown - is actually just a small structure containing pointers to the data, and so the values which gets copied during function calls are in fact memory addresses and changes *are* visible everywhere. Whoops! Any easy fix, though.

Then when I wanted to create an Atom feed for my new gemlog I ran into the unavoidable limitations of gemfeed's naive strategy of using each post file's "creation" time to set the timestamp in the feed. I deliberately didn't use file modification times for this, because it's not uncommon for me at all to edit a post in the first day or two after it's made because I spoted a typo or somebody has pointed out I pasted a link incorrectly or whatever. These kinds of small changes don't warrant changing the timestamp in the feed. I want that timestamp to reflect when the file was *created*. Unfortunately, unix filesystems don't actually expose that information, and the `ctime` function in Python's standard library gives you the last time the file's metadata (e.g. ownership, permissions, etc) change. That's kind of the same thing if you don't change the metadata after you post, but it has become apparent that some people maintain their capsule with scripts that have `chmod` calls on *.gmi or whatever, which breaks the whole thing. For this reason, gemfeed also recognises YYYYMMDD timestamps at the beginning of filenames.

In my case, copying the old post files into a new directory for my new gemlog obviously resulted in a bunch of new files all having the same new apparent "creation" times, which meant the filesystem based timestamps were all wrong. Renaming the files to include their original post dates in the filename would have made it a lot harder to write redirects from the old URLs to the new URLs. So, I had to update gemfeed to accept a --mtime option, which tells it to use file modification times instead of "creation" times, and then I used `touch` to explicitly set those timestamps correctly (`touch` doesn't let you forcibly reset the "creation" time, and no other tool does either). It's working now - once I've made 10 new posts in the new gemlog, I should be able to switch the --mtime option off to regain the ability to make small updates without changing the date. I probably *should* adopt a convention for new posts of putting the date in the URL, to save me from this ever happening in future...but I haven't. I like clean URLs, and I like being able to write links from memory - I wrote the link at the start of this post to my previous post by just typing "identity-crisis.gmi" (yay for relative links!) from memory. Having to look up timestamps for old posts and copy and paste them in would be a drag.

Anyway, the whole schemozzle is just about over. I'm looking forward to being able to post in Geminispace on any subject I like now!