In the last week, I’ve spent a big chunk of time refining the Chimera-md server software and my own installation of it. I’m making progress! The most notable item is that I started working on a logo for the server, which you can see above. It needs a lot of work, but you can see the direction I’m leaning with for it. I haven’t added it to the design yet, though.
Breadcrumb trail updates
I like the generated breadcrumb trails in the nav area, but there was a clumsiness specifically with index.md files. For a URL like /path/to/my/dir/index.md, you would get 4 link elements — “path”, “to”, “my”, and “dir” — and an unclickable text tag for “index.md”. The problem was the “dir” link would redirect to /path/to/my/dir/index.md, which is exactly where you started. Now I clip “index.md” off the end if exists, making “dir” plain text in this example.
Plugin support
A fair chunk of the markdown documents I’ve been hoarding over the years are scripts for comics I have written (and largely not shared). Now that I am able to regularly view them with nice HTML formatting, I decided to invest in getting them more readable. I decided to make an update for “dialog” styling.
I found a way to make it work with <code>
blocks, with little speaker tag attributions. It worked with a combination of scraping in the HTML code generation and a little bit of jquery. But when I went to apply it to my documents, I found the oversights in that approach. I lost the ability to include styling tags in the dialog. What’s a comic script without the occasional **bold** text? I was also uncomfortable with extending the scraper in this way — if there’s a code block preceded by a **strong** tag, they must have intended to make dialog…
So I changed it up some, rooted around <blockquote
> sections instead (which still allow styling), and the use of yaml-style frontmatter tagging to explicitly request the application of the dialog styling.
---
plugin: dialog
---
# Title
The rest of your markdown
This frontmatter doesn’t print; you can put anything you want in there. But if there’s a line with “plugin: whatever” there, the generated HTML will add jquery and “/home/script/whatever.js” javascript request that you can use to apply additional processing as needed.
Cache size control
In the original implementation, the server caches HTML results for markdown files. It’s a pretty simple optimization that speeds things up a lot. But it had no cap on how much would get cached, which meant the server could take an unbounded amount of memory. I now tag each cache item with a timestamp, and have a command-line parameter to control the maximum size the cache can get to. The default is 50 megabytes. If the cache exceeds that size, the oldest entries get pruned.
Docker volume mapping
I noticed at one point Docker was leaving some empty directories in my document root on the real file system. If I deleted them, the container would fail to build, complaining that because the document root was read only and it couldn’t create them.
I have multiple, disconnected folders on my drive that I turn into a single hierarchy with Docker volume mappings. Here are some example mappings:
volumes:
- /Volume1/homes/acbarrentine/Documents:/data/www:ro
- /Volume1/homes/acbarrentine/Receipts:/data/www/Receipts:ro
- /Volume1/homes/acbarrentine/Taxes:/data/www/Taxes:ro
I figured Docker handled these internal to the container. It turns out it’s using mount --bind
for these mappings — real file system calls. The indirections in the mapping are handled by Linux live, not something internal to Docker. To make “Receipts” and “Taxes” folders appear inside “Documents”, the bind mounts require a folder. Unfortunately, the folder doesn’t get deleted, even if you delete the container.
For the time being, I’ve made some of these mappings not read-only so Docker can do the bind mounts. I also unabstracted the site.css file I was using, moving it into the real Documents folder because the mapped one not only had one of those bind mount files, changes to it tended to not get noticed without restarting the server. File bound mounts are inode-based, and editors tend to use the “write a temp file and rename” pattern on save, which changes the file’s inode.
Things are starting to settle into a comfortable space for the server software. Beyond the logo, I’m not sure what are the next steps to take with it. Ideally, I’d like to get a demo server for it someplace. That might be more useful if I could get it directly editable, though. A view of just the HTML output doesn’t really show off what is special about the server.