MeatballWiki | RecentChanges | Random Page | Indices | Categories

Should we move to a different WikiEngine?

Someone else suggested OddMuse.

OddMuse sounds good. I'm still in favor of some sort of community programmable wiki, but let's do one thing at a time.

If we end up using my implementation, most of my CPW framework can be added onto any Perl wiki anyway. There are a few UseMod specific parts, but since OddMuse is a UseMod derivative that should be easy too. I bet it'll be around a 4 day project, depending on what one considers a "day". So we can ignore that for now, and focus on moving to OddMuse.

As we move to OddMuse, let's use a style-sheet (or whatever it is; I'm not up on this technology) to make headings, etc. look like they do on MeatballWiki now. We can change the style-sheet later (one thing at a time, right?).

-- BayleShanks

I think oddmuse would be a reasonable starting point, from the little I've seen. I'm not sure we'd want to be a full CommunityProgrammableWiki, but there should be community-based ways of choosing all the options, just as for the InterMap. --MartinHarper

AlexSchroeder pointed me at http://www.emacswiki.org/cgi-bin/oddmuse?Migrating_From_UseMod_0.92 to see what is involved in migrating from UseMod to OddMuse. Unfortunately, as we've since established by email, it's not as simple anymore.

 this is pre-formatted and would not not link to ChrisPurcell

I favour changing the parser of OddMuse to mimic UseMod when we install it on MeatballWiki. Alex points out it would be harder to maintain afterwards, because we'd essentially be maintaining our own copy of the parser "core" function. He suggests going through the 2448 pages we currently have on Meatball (gosh, that was 2447 a couple of minutes ago...I spy MultiCopyrightWiki on RecentChanges) and changing them all. Actually, he suggested changing as many as possible before getting bored, then fixing the rest as they crop up through PageChurn, but I'd note that many people follow external links to random pages here, and will be nonplussed if the page looks...odd. So, changing all of the 2448 is probably the only way to go. Including SunirShah's diary. I still think changing the parser is better.

Of course, since Alex will be the one installing the new script and changing the page database, it's up to him.

Anyone with objections to changing the parser rules from MeatballWiki's current brand, this is the space for it. -- ChrisPurcell

Unless any of the subtle formatting changes are unsubtle, I say "converting" 2,500 pages is easier. Most of them won't even use pre-formatted text. If anything important gets broken, it'll be fixed soon enough. --MartinHarper

I think the pre-formatted text thing is unimportant; there isn't that much pre-formatted text lying around (in fact, I think the whole "indent for pre-formatted text" thing is a bug, not a feature. I never use it and it makes copying & pasting text from other places harder). The PageClusters thing is important, as it'll break any page which starts with a page-name. Let's just turn off PageClusters initially. Are there any other unsubtle problems?

-- BayleShanks

List items can be continued on the next line. Example:

and this belongs to the same item.

This affects several pages for sure, but is easy to fix. -- ChrisPurcell

Well, my burning question is this: what does OddMuse offer us over UseModWiki? What problems are we trying to solve? -- StephenGilbert

OddMuse has an active developer who understands it fully, and is also an active member of MeatballWiki. It's also derived from UseMod, so presumably will handle the same loads as Meatball currently can. -- ChrisPurcell

I operate several wikis, public wikis like digital rendezvous [1], closed ones to support change in corporations, one for my business website [2]. About a year ago, I migrated all of them to OddMuse. The main reasons where multiligualization, good documentation and enough functionality instead of too much.

-- HansruediHaenni

One thing that worries me is the appalling page load times I've seen on CommunityWiki. Is this the engine or the server, Alex? -- ChrisPurcell

Much improved due to your hint that /m is expensive. Thanks. -- AlexSchroeder

Alex has solved the KeptPages problem in OddMuse. It now uses separate files for each version. We can deal with formatting fallout after the fact (BarnRaisingNominations).

The other issue is to add PageClusters, in a format we agree on (i.e. not the current OddMuse format, without debate at least). -- ChrisPurcell

I want to replace the parser with something that emits XHTML (cf. InfiniteMonkey). Part of this work has led me to a mental model for WikiSyntax which could hopefully be useful in automating translation.

Other problems are multilingual fixes (UseMod damages UTF8), better InterWiki support, and a more HumaneInterface. Basically OddMuse is what UseMod 1.0 was supposed to be. Just because Alex did it and not Cliff or I doesn't undermine the fact that is what MeatballWiki was planning on running. -- SunirShah

I actually tried twice whether Oddmuse would be difficult to move to XHTML. The first attempt failed because list items parsing had bugs. The second failed because I still don't have the placement of paragraph closing tags fixed. But I hope that we'll get there eventually. I'm using a state-machine like parser inspired by ScottWalters' TinyWiki. -- AlexSchroeder

Have you looked at the InfiniteMonkey parser? It isn't a state machine, which makes it easier to modify. -- SunirShah

I (CliffordAdams) support moving Meatball to OddMuse if that is what the most important community members want. The markup differences are fairly minor, and it would be good to have more active support of the software. PageClusters seem like they could be very helpful. (I originally planned for SubPages to be clustered on RecentChanges, but the RecentChanges code grew too unwieldy to add this feature.)

My main concern is whether the current usemod.com host (futurequest.net) will be able to support a growing community, especially if OddMuse can be more resource-intensive at times. (Problems could develop with disk space, CPU, and bandwidth growth.) I am willing to continue hosting this wiki in the near term, but perhaps it should move to another host someday. (I am willing to maintain redirection from usemod.com as long as I can--it could be mostly transparent.)

Finally, while we are discussing major changes, perhaps MeatballWiki should get its own domain name? I'll start MeatballWikiDomain? for further discussion. --CliffordAdams

When I called futurequest, they explicitly said that they were not going to install a bandwidth throttle, and they reserved the right to disable my wiki when there was too much load. Which is why I moved to thinkmo.de instead. -- AlexSchroeder

The difference between futurequest and most other providers is that they will re-enable your site when the load subsides. (Most providers will cancel your account once it causes problems for other customers.) I saw a CGI script on FQ get a major Slashdotting (which pretty much stopped the system) but it was re-enabled the next day. Bandwidth is an issue, but I get 18 GB/month (currently using less than 10GB/month) and I can get more for $5/GB. --CliffordAdams

Basically OddMuse is what UseMod 1.0 was supposed to be. SunirShah and I have had a few disagreements in the past, and this is yet another one. :-) I would have liked to add more language support and much better documentation (points in OddMuse's favor), but I strongly disagree with some decisions made in OddMuse. I'm glad AlexSchroeder wrote OddMuse, but it wasn't my vision for 1.0. --CliffordAdams

Sure. ;) What I meant was that OddMuse was an active project reflecting Meatball design issues. UseMod and Meatball may not necessarily agree with each other. -- SunirShah

Curious about these decisions. :) Oh and Sunir: What about that holiday?! -- AlexSchroeder

The main decisions I disagree with are those which make the script less friendly for some users in order to save a few lines of code. Using only UTC 24-hour time is almost as annoying for USA users as "EST/EDT" 12-hour time is for European users. SubPages are also useful for several users, although I understand they are a pain to maintain. Removing renaming and immediate deletion is another example. Finally, some of my core design decisions were that ordinary page loads will only open one wiki page (OddMuse can open a configuration page and an InterWiki page for each load), and ordinary page loads will not do any writes (like OddMuse does for referral tracking and (optionally?) throttling).

All of these changes can be justified (I wouldn't implement SubPages in a new wiki project), but they do make OddMuse quite different from its parent. This diversity is a good thing in my view--in fact I just added a link to OddMuse from [the UseModWiki download page]. I want people to try lots of wikis and then select the best one for their needs (even if it isn't mine :-). --CliffordAdams

Ah, I'm relieved then. Those decisions were hard for me to make as well -- UTC, subpages, no immediate removing and deleting (although the search&replace functionality + redirection + page deletion partially make up for this). Actually Oddmuse will do even more writes: After an edit the cache is updated in the page file and the visitor file is updated even if surge protection is disabled (and visitors remain enabled). Thanks for offering this feedback. Mind if I copy an edited version to UseModWiki? -- AlexSchroeder

Please feel free to copy and edit that text. --CliffordAdams

The decision about TimeZones is simple. Follow MoinMoin's example. List the relative time since the last change, not the absolute time it was changed. After all, this is what the users actually want to know.

This is a good idea in the short term, but I think it breaks down with larger amounts of time. I would rather know a page was edited in March 2002 than "500+ days ago" (or even "1 year, 7 months, 18 days"). (Hmmm... Maybe I could make it an option or user preference. :-) --CliffordAdams

I recommend we have PageClusters (in the form Alex currently uses) disabled, to avoid the immediate hassle of explaining it, coping with it, then probably changing it. I also suggest we set up the header/footer links as they are now. Other than that, I agree. -- ChrisPurcell

I'd like an "Edit text of this page" link at the top too. I know, this is sacrilege. I have to go and amend my previous argument against it to make it clear that I am an idiot. -- SunirShah

Sacrilege indeed! The top link bar is a tad unwieldy already, though I guess we'll no longer have Preferences. How about an access-key instead? Then you can hit Alt+I,Enter (for example) anywhere on the page to edit. -- anon.

Motion to go ahead. I move that we go ahead and replace the script with OddMuse when Alex is ready regardless of whether we have reached consensus yet on PageClusters, "Edit text of this page", and any other minor issue. We can change/turn these on or off later.

My comments on minor issues:

-- BayleShanks

The general strategy is to use the mb2.pl or mbtest.pl scripts first. You may want to copy the page database for testing if you have to change the file structure. Make sure that script incorporates the patches in mb2.pl (UseMod 1.0) we need to host MeatballWiki effectively on usemod.com, such as the better login stuff. Ask Cliff more about that. He's returned to life. -- SunirShah

Sorry; forgot OddMuse has no logins. Anyway, you should check out the patch list of UseMod 1.0 first. You may also want to use a nicer diff than Alex's, which isn't very good in my opinion. Don't forget to find all the Meatball specific patches. (They are noted.) -- SunirShah

Interesting formatting observation: everywhere we currently write [CategoryName?] will show up as a [1] link instead. BarnRaisingNomination: go through [3] and fixup the markup. -- anon.

If someone is interested, WikiGateway could be used to write a GlobalReplace for this pretty quickly. There's no OddMuse support as yet in WikiGateway, though, but it should be easy to add. -- BayleShanks

Oddmuse has global search and replace for administrators. -- Alex.


I'd like AcademicCitations at some point. -- SunirShah


In early testing, we found minor formatting problems, but page generation was slow (no longer sure this is the case; much has changed). Alex implemented a [4] for those who like that aspect of UseModWiki. Sunir suggests the InfiniteMonkey parser as a drop-in replacement:

The syntax is simpler, but we can return it back to UseMod syntax, or alternatively convert the whole PageDatabase. It is currently missing the ISBN pattern (not important), #REDIRECTs (easy but I prefer PermanentAnchors), and TableSyntax, which I was going to do next, although I was contemplating changing it to something less stupid. There are a number of syntax differences that can be removed (copy&paste from my local version):

heading 2

=== heading 3 >>> Indented text
foo :foo

(*) For a speed comparison, compare SunirShah vs. http://www.usemod.com/cgi-bin/next.pl?SandBox (I copied my name-page). Not a true test, but a close one. Look how nice the source of the page is though. The overall output could be speeded by removing unnecessary whitespace. -- SunirShah

P.S. Here's my conversion script:

sub trans {
    my $string = shift;
    my $c = shift;
    $string =~ s/./$c/sg;
    return $string;

while(<>) {

I wrote a sample simple and fast parser replacement for Oddmuse based on regular expression search and replace. [5] It is regular expression based. Adding more rules should be easy for Perl people. I'm not really interested in coding up all the existing text formatting rules. Perhaps somebody interested can take up the ball from here. -- AlexSchroeder

Nothing can be as smooth as you want. Problems we have to fix; please add (assigned):



MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions