MojoMojo is probably the most powerful and flexible open-source wiki application available today. Based on Catalyst and Perl, MojoMojo is gaining momentum and notoriety for it's flexibility and modern web-application features. Today we get the opportunity to speak with Marcus Ramberg, the creator of MojoMojo.
I first started working on mojomojo as a project to learn the new MVC framework Maypole. This was back in 2005, and as it became apparent that the Maypole project wasn't going anywhere, I ported MojoMojo over to Catalyst. I remember the transition as being fairly easy. Back then we were also using the Class-DBI ORM. MojoMojo has long since been ported over to DBIx-Class. This happened at the Hackathon connected to YAPC::NA in Chicago.
There are so many different wiki packages out there, what made you start a new one?
It doesn't use prototype anymore though, right? What library is it using now? Why did you choose that?
You mentioned that you originally worked with Kwiki and found it's base on version control to be problematic. MojoMojo has versioning on page edits right? Were there any challenges making that work well?
Sure, MojoMojo has full versioning and diff between older revisions. The entire storage is handled by DBIx-Class, which made it fairly easy to implement. The other hard lifting is done with some handy CPAN modules, most prominently Algorithm::Diff.
What do you feel sets MojoMojo apart from other wiki software?
A major difference in how it works is the whole tree-based system. Rather than having a 1 or two level wiki namespace, MojoMojo supports unlimited levels of nesting of pages, for instance /Engineering/Meetings/Development/2008-01-01 would be a perfectly valid wiki node in MojoMojo. We also support a very powerful ACL mechanism which lets you set permissions rules on any level of the tree.
Also, as I mentioned above, we're providing a rich user experience, for instance, we generate live previews of the wiki markup as you type, as well as the toolbars you traditionally see in other wikis (for instance mediawiki). We also provide batch uploading with progress bars. Once you've uploaded some images, we autogenerate galleries for those attachments.
That sounds neat. Are the galleries page specific? Are there any other media related features in MojoMojo? Are you thinking of adding any more?
Yes, the galleries are per page, but you can also categorize them with tags, which gets aggregated downwards in the tree structure. There is a formatter that lets you embed entries from amazon based on their URL, and there's a youtube one in the works that will make it into the next CPAN release.
I've also started work on an OEmbed formatter, which seems like our best bet at programatic embedding other content at the moment. OEmbed works by querying each site for their embed code based on the url. Hopefully it will get widely adopted.
Do you have any specific goals for the MojoMojo Project?
The most important goal now is to reach 1.0, and freeze the final details of our wiki-syntax. From there, I mostly want to make MojoMojo even more customizable and extensible.
I know MojoMojo has worked with various markup libraries and modules, Markdown, etc. Is MojoMojo's syntax a hybrid now? How do you see this developing over time?
The syntax system of MojoMojo has always been pluggable, so that which primary formatter to use (Textile and Markdown at the moment, but others could easily be supported) is a system-wide choice. This also means you can easily write your own custom formatters to do things like parse irclogs or embed widgets.
The system currently works using Module::Pluggable::Ordered, so that the formatter chain runs in a predictable order. However, we are considering supplying this with using Template Toolkit so that many plugins can just be written as functions or filters in TT.
Currently, we have about 8-10 people who contribute regularily. Historically we've had a lot of other people who've contributed source to the project though.
I think it's pretty fair, considering that we haven't been on CPAN that long, and that we still haven't reached version 1.0. I believe that one of the barriers to adoption has been the heavy dependency chain of MojoMojo, which is one of the reasons I was pleased about it being packaged for FreeBSD recently. I also hope to see a debian package of it in the near future.
I think a lot of the power of MojoMojo comes from all the great CPAN modules we use. Of course, it can be an inconvenience to have to wait for all the tests to run, which is why it has been important to me to find alternative distribution methods like FreeBSD Ports and Shipwright. However, I think it's more important that the tests pass. I think that the relentless work of the CPAN smokers [cpan testers -ed] has been instrumental to build a product on the shoulders of as many giants as MojoMojo has done.
Test reports also show up in search.cpan.org, so a tip would be to check smoker reports from modules you consider using in your open source project.
There has been some work in this area, both using PAR (Catalyst supports building PAR archives of your app), and Jesse Vincent's Shipwright system. We hope to have this in place for the 1.0 release. The disadvantage of the PAR approach is that it is architecture specific, so we would have to distribute separate distributions for each OS.
The project has been a very long running one for me, but I really feel that it's just recently gotten more attention. I thing the future is bright for MojoMojo, and I am excited to see what all the other brilliant developers contributing their time to the project comes up with.
Thanks to the open nature of Git versioning, we're now even getting contributions from people who haven't even talked to us. I think it's brilliant when I get a pull request in the mail from someone who's forked the codebase and written a DocBook formatter or some other useful addition to the project.
I don't personally plan to start any encyclopedia, but I think it could absolutely make sense as one. For instance I think it would be well suited to implement the kind of workflows in use by the national Wikipedia competitors.