2020-01-01 What about Oddmuse?

Yeah. What about Oddmuse? Am I going to reinvent everything and implement in Raku (i.e. Perl 6) – or do I keep working on what we currently use and stick with Perl (i.e. Perl 5)?

Just now I’ve skimmed the list of Revolutionary Changes we could attempt for Oddmuse. Perhaps this choice between Raku and Perl has been paralysing me as well?

I keep getting back to this because I feel Oddmuse could move towards typical static site generators with an online editor, basically.

I would like to separate the page files into three files: the raw text file for easy editing, checking into a version control system, backup, and so on; the static HTML file for quick serving using a dedicated web server; and the metadata for the current version of the page.

This means that I also need to get rid of “dirty” text formatting rules. The original issue has been that a link to a non-existing page would render differently (remember that question mark after a WikiWord?) – but these days I think we might simply ignore whether a target page exists or not. I’ve been using such a setup on this site (my homepage) for quite a while and noticed no adverse effects.

We would also lose things that didn’t turn out to be too popular, anyway: transcluding pages from elsewhere; transcluding RSS feeds. Those features would simply disappear and it would be hard to get them back. We could, if we wanted to, move their code into a separate action and replace the inlined HTML with a link to the new action. It think it would be just as well.

I'm pasting images into the blog more often. The problem is that the move to HTTPS made it really hard to hot-link external content. Sure, if you knew how, you can setup your HTTP headers to do the right thing. But whoa! Isn’t it better do disallow that anyway? No more bandwidth stealing from other people. No spying on you by using images from servers that might be tracking you.

That’s why better uploads are on my mind.

If we have better uploads, we might also get rid of the “upload file on a page”. I still love the idea. But in practice, I fear it failed. I never met anybody who loved the idea. I know, sad! But once we decide to no have images as page files, or as a special kind of page file, we can think about moving comments into a special kind of page file (instead of relying on a visible prefix).

And once we’ve gone this far, perhaps we can do the same with day pages? I know that I almost always write [[2020-01-01 Foo|Foo]] when I link to other pages on this blog.

Et tu, CGI.pm. Yes, you. What should we do? With Oddmuse 6 I tried to use templates for all the actions and it worked surprisingly well. Perhaps we can start doing that for Oddmuse? Then we abandon CGI both for the generation of HTML and for the use of Oddmuse as a CGI script. In fact, we could move to Mojolicious 100%. You can still use a Mojolicious app as a CGI script, I hear. It’s probably slow. But then again, at least it still works.

So much to do, it’s true. But I know myself. What shall I do when summer break 2020 comes up? It pays to be prepared. I loved that energy when Alex Daniel was totally into Oddmuse. We made plans. We got shit done! 🙂



For what it’s worth, I found the OddMuse way of dealing with images much easier than PmWiki’s attachment system, and used it accordingly. But yeah, comments and day pages could be better handled. Not that mixing a blog and a wiki worked all that well for me. The two are fundamentally different media. And the promise of reworking old blog posts into more permanent article is moot when you have to copy-paste manually anyway. Assuming you’d even want to destroy your own historical context.

Felix 2020-01-05 12:36 UTC

I guess you could say that it didn’t really for me either: I ended up having a blog built on wiki tech, but not on wiki culture. 😒

– Alex Schroeder 2020-01-05 12:52 UTC

Perhaps because a blog built on wiki culture is an oxymoron. 😉 It’s also kind of pointless. What exactly stops anyone from going back and editing old blog posts on an ordinary blog if the need arises? What advantage does a wiki provide here? OddMuse was just what I needed to rescue my old website, for a number of reasons... except for those parts that were better off turned into static pages, like the game library and blog archive. And more content might end up having the same fate. It’s not like I have any collaborators left to worry about.

Felix 2020-01-05 18:59 UTC

Absolutely true. And for me and my RPG interest I have a related problem: I sometimes revise my ideas and so I could in theory write a wiki and keep it in the Wiki Now, forgetting the past. But no, I keep posting blog posts, linking to old stuff, never quite assembling a document collection for a snapshot in time. Like time and dust, things accrete and sink deeper and deeper into the past, and new layers cover everything.

I guess in the end it is a question of affordance. The wiki allows us to pivot and change precisely because it has so little built in blog-supporting structure.

– Alex Schroeder 2020-01-05 20:22 UTC

Which reminds me. Before the big change, No Time To Play was all blog, and that meant content that should have been timeless ended up buried. Even tags and categories weren’t enough of a fix. But in the middle of the big migration I found that, conversely, some of the content needed to stay chronological. Even if parts of it also ended up in the wiki now.

Well, “wiki now”. Even on the wiki, all articles have their original publication date at the top, unless I forgot to add it. No matter what, we need the historical context.

Which, I suppose, is also why in practice most wiki pages remain in the form of a conversation, with little if anything moved to the top. Go figure.

Felix 2020-01-06 07:15 UTC

Like this conversation...

– Alex Schroeder 2020-01-06 07:42 UTC

Please make sure you contribute only your own work, or work licensed under the GNU Free Documentation License. Note: in order to facilitate peer review and fight vandalism, we will store your IP number for a number of days. See Privacy Policy for more information. See Info for text formatting rules. You can edit the comment page if you need to fix typos. You can subscribe to new comments by email without leaving a comment.

To save this page you must answer this question:

Please say HELLO.