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)?
- There’s the question of the web server framework: Raku has Cro but somehow I never quite got to grips with it and I have slowly warmed to Mojolicious.
- There’s the question of markup rendering. Oddmuse 6 has a few Markdown modules, but the ones I looked at didn’t use Raku Grammars, and I was unable to implement one myself. I never quite figured out how I would compose Grammars in order to allow users to have per-site text formatting rules. Then again, this state machine based parser I’m using is still slow. Too slow?
- Sadly, Oddmuse 6 takes a lot more memory.
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! 🙂
Tags: Oddmuse