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.
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.
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.
#Oddmuse
(Please contact me if you want to remove your comment.)
⁂
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
---
Via a web mention:
In the spheres I follow there’s been a big push lately for protocols like gopher and gemini, a form of expression that crushes the entire possibility space into the pre-HTML basics: text, hyperlinks, and files. I understand the sentiment. The web has become so overgrown with weeds and tangles of an ever-growing and always-”innovating” spec that it’s tempting to just want to scrap it all and start tabula rasa.
I dunno, I appreciate the minimalism, but for me, plain text is an over-correction. It feels too stifling. I want my page to look at least a little unique (and I’m not that into ASCII art.)
limitations can be freeing, by matt
---
You don’t need to worry about Raku anymore now that Perl 6 is coming.
I personally think blogs and wiki mesh well together. I ran my old blog on a wiki (that hosted many blogs) and has now instead attempted a wiki-like way of thinking around my static Jekyll blog.
– Sandra 2022-04-17 09:03 UTC
---
You mean, Perl 7 beats Raku somehow? I guess I could still sit there, wondering what my preferred la language is going to be. Then again, I guess Phoebe proves that I’m sticking with Perl.
– Alex 2022-04-17 15:06 UTC