2008Q4 Grant Proposal: The Mojo Documentation Project

  • Name: Sebastian Riedel
  • Project Title: The Mojo Documentation Project
  • Synopsis: During the last few months i've done some self funded work on a next generation web framework named Mojo. It is now quite close to a public release and needs documentation.

Sebastian Riedel

Project Title
The Mojo Documentation Project

During the last few months i've done some self funded work on a next generation web framework named Mojo. It is now quite close to a public release and needs documentation.

Benefits to the Perl Community
Mojo is not just another web framework, it is more of a framework for framework developers.

When you take a look around you will notice a trend towards very specialized web frameworks, more and more of those are released every day. (Not just in the Perl Universe) Many are extracted from web applications and optimized for a given task like writing blog engines.

These frameworks might look very different on the surface, but they all share the same foundations and unneccessarily reinvent a lot of wheels.

What Mojo offers is a very convenient runtime environment for web frameworks providing reusable wheels like CGI/FastCGI bindings, test server, test framework, code generator framework and much more.

The Mojo framework is not a monolithic brick like Catalyst, instead it has multiple layers that could be used independently if desired.

  • Curse: The pure-Perl HTTP 1.1 client/server implementation that powers Mojo, with CGI/FastCGI support, async io based client designed specifically for stress testing web applications and a solid test server. Curse could be considered the LWP for the server side.
  • Mojo: A generic mainloop for web frameworks with request/response abstraction, code generators and test helpers. Also contains generic dispatchers and views that can be used for simple web applications. While everything was designed with MVC in mind other architectures are possible too.
  • Nevermore: Simple OO-Perl helpers designed for portability, not using any magic that could make it harder for new Perl users to understand whats going on.
  • Voodoo: A minimalistic and very Perl-ish template engine designed to be mainly used in code generators. Quite similar to Ruby's erb.
  • "Unnamed": A cache and session framework is currently in the works, but might not be ready for the first release.

Another killer-feature of Mojo is that it has no prereqs except for Perl 5.8, which should boost it usability wise into the same league as PHP.

Mojo was also designed with a Perl6 port in mind from the start, this and having no prereqs, should make sure that Mojo will be one of the first feature complete ported Perl6 modules available, imagine that! :)


1. A substantial manual for the Mojo web framework containing at least the following chapters.

  • GettingStarted
  • CurseGuide
  • FrameworkBuilding
  • Cookbook
  • CodingGuidelines

2. Some people learn better by reading code, so we will also need 3 example applications demonstrating all important aspects of Mojo.

  • MojoApplication
  • MojoFramework
  • RebrandedMojoFramework

3. To make the whole project more accessible to the community, i will also be blogging for the whole duration of this grant. Blog entries will contain short introductions to Mojo and mostly recipes from the cookbook. Reader feedback will be used in the writing process to increase the quality of the manual.

Project Details
The manual will propably take most of the time.

  • GettingStarted: A tutorial written for people who might have never used Perl before. Back in the days i learned Perl by writing scripts with CGI.pm, which was a hell of a lot of fun. Times have changed, CGI.pm is dead, but Mojo can provide the same great experience.
  • CurseGuide: A complete reference guide to the HTTP 1.1 client/server implementation that powers Mojo. From simple GET oneliners to complicated edge cases like 100 Continue or chunked encoding.
  • FrameworkBuilding: A framework builders guide containing everything from writing your first dispatcher to rebranding the whole framework for CPAN distibution.
  • Cookbook: Many many recipes like "How to stress test your application without using fork() or threads in a simple unit test" or "How to implement your very own micro-PHP".
  • CodingGuidelines: A small collection of coding guidelines for contributers and the mission statement of the project. To make sure the original vision never gets lost like it happened to Catalyst.

Not less important but a bit easier are the examples.

  • MojoApplication: A simple application utilizing everything Mojo has to offer to application developers, like serving static/dynamic files with built in dispatchers, voodoo templates, unit tests and much more.
  • MojoFramework: A simple example web framework, demonstrating how to use Mojo as a runtime environment, including a custom dispatcher and template engine.
  • RebrandedMojoFramework: A more advanced example web framework, completely rebranded and ready for CPAN distribution, with everything from custom code generators to a custom test framework.

Project Schedule
This project should take me 2 to 3 months.

Sebastian Riedel is a freelance Perl programmer living in northern Germany and the founder of the Catalyst project. (http://catalyst.perl.org)

Amount Requested



the clean and complete HTTP/1.1 implementation of Curse is an excellent project, that can be reused by a lot of other projects.

That part alone is worth the grant.

Best regards,

Some updates, since the proposal was submitted 4 months ago.

* Curse and Voodoo were just code names and got merged into the Mojo namespace.
* We now have a marketing website at http://mojolicious.org.
* Mojo is already released and available via CPAN.

This is a very cool project. Its relative simplicity, pure Perlness and it ability to scale from CGI to mod_perl is wonderful. Ditto about the comment melo made as well.

However, it needs serious documentation. Please fund the grant.

Such application can give you possibility to create your own framework. Very exciting without getting too deep into HTTP magic. Looking forward for more documentation and not yet written parts.

Certainly it is worth the grant, because other frameworks have more control over you. I think it should be the opposite.

Such application can give you possibility to create your own framework. Very exciting without getting too deep into HTTP magic. Looking forward for more documentation and not yet written parts.

Certainly it is worth the grant, because other frameworks have more control over you. I think it should be the opposite.

I would like to stress how good is this as a building block for other frameworks (with my experiment to port Moose-based toy to Mojo -- starting with this commit in just few simple steps). I'm still impressed how dependency free Mojo is :-)

yes please ..

Mojo is great! It is that I so wanted for a long time.

I'd love to see a complete documentation of Mojo (and mojolicious)...

IMO, it's not just yet another web framework. Sebastian's simple way to explain how to dissect dispatcher on his blog clearly shows one of its power.

I can't get behind community funds going towards documenting re-invented wheels.


I'll answer to that by quoting myself.
"The web is a moving target, things need to move forward, bi-directional HTTP is happening. What Mojo provides is a replacement for the ancient and RFC ignoring modules Catalyst was built upon, we are ready for Comet and WebSocket for example."

Some wheels just have to be reinvented.

Mojo ist more diversity and this will result in some more evolution in Perls universe.

I support a good documentation for Mojo.

I think good documentation is crucial to get people on board, and Perl has been losing that battle for a while (even if the competition's documentation are screencasts).

The "read the code, it's all there" attitude is good enough for seasoned programmers, but it won't attract any new blood, that's for sure.

We should really all support this framework. Its simplicity will make it basis for lot of other projects. Making good documentation for it, will be great step towards it.

This project fills a void. I also like the 'few dependencies' approach. And good documentation (or the lack of it) really makes or breaks any free software project.

Mojo looks really good but documentation is key. Please fund Sebastian for this.

( When I tried to use my Flickr URL for Open ID auth, this error was returned:
Undefined subroutine &Compress::Zlib::memGunzip called at /home/mt/MT/extlib/URI/Fetch.pm line 111 )

Although I maintain CGI::Application, which could be seen as competing, I support this effort. I have reviewed Mojo in depth, and have found it to be well designed and easy to follow. It it truly "loosely coupled" as sri suggests, and like others I consider the lack of dependencies a major feature. Having no dependencies will make it easier to deploy Mojo-based applications, which is an area where Perl currently lags behind some other languages.

From my own benchmarks, Mojo / Mojolicious could even run decently in a plain CGI environment.

As a proof-of-concept I successfully tested running CGI::Application with a Mojo handler, using the Mojo request object within CGI::Application.

That demonstrated for me that the potential is really there for for multiple web frameworks to be built on this and still share some common functionality.

I do not see wheel-reinvention here, but evolution. Cruft from previous generations has been dropped or re-throught and the result is a system of modules that are all written in a style that is consistent and easy to follow across the code, documentation and user interfaces.

This framework is very promising. I was really needing Mojolicious docs.

I believe Mojo is the breakthrough in perl-way web-development. At least, for the time being it looks impressively flexible, transparent and intuitive. Almost like Perl itself.

I find the framework very interesting. I hope to see this proposal funded!

I agree that this proposal should be funded. (For one thing, it clearly won't require much funding.)

My point-of-view is this:   I am launching a brand-new web project (last week...), and I already know that it will be just-as-much involved with iPhones and Androids on the front-end as it will be to “the web.” I know that the total project will also involve RPC-servers (talking to non-web apps) and JavaScript (for the browsers). The app is being built from the ground-up with Moose. In short, my requirements call for me to start from “the state of the art as of January 2009” with no regard for the past and no desire to carry it forward. I fully realize that this is the exception and that what I am doing will become “crufty legacy software” soon enough. :-)

What I need for this new app is “clean and mean” ... a dispatching-framework and a bare minimum “to me, unnecessary things.” This app is not actually going to be the center of most of this particular new universe. I've selected Mojo(licious) as the base, after carefully considering the other (as of Jan 2009) contenders. What I am looking at deserves documentation.

I've been watching Mojo and have enjoyed its direction - that less is more and no dependencies. I prefer installing CPAN modules that have no or little dependencies. These tend to be lighter, written cleanly, keeps things portable and DWIW.

I look forward when I can promote Mojo at work. But I would need adequate documentation/cookbooks to make the "sale". I've got to let Mojo & it's docs sell itself in the shop - otherwise I'm another framework/template zealot that will make things more complicated.

Why does this matter? I work at Fortune 100 company (though I'm not representing them here.) We have many corporate flavors of Unix, some Redhat & Windows servers to boot. We have Perl 5.005 through the latest ActiveState Perl. Many servers don't even have a proper DBI since we aren't allowed to have compilers on most servers (which means mostly forking SQLPlus, DBI PurePerl or LWP-RPC requests). And, we cannot pollute any systems sitelibs (by lazily installing via CPAN), everything is local.

That means no Catalyst, Maypole, CGI::Application (since we can't use some desired plugins.)

In fact, the only reason we can use Perl (unsupported) is it comes default on our Unix/Linux server builds. There's no en vogue language like python, ruby, php, etc. - just POSIX Shell (ksh) & Perl.

But work has to get done and Perl is there every time. We really need a modern framework to leverage. To this day and going forward, we have to cobble modules together based the most common lowest-common-denominator - Perl 5.8 basic install, no compiler and minimal module dependencies.

The alternative for us would be to make everything a Microsoft C# ASP.NET or Java app. That's too heavy handed and the wrong direction for some quality glue that must be executed Unix server side.

Again, to make pitch and sale, having great documentation is requirement of any quality component or library. I believe Mojo can bring some desperately needed consistency and portability across many kinds of production servers. But, since Mojo doesn't have it's own O'reilly animal yet, I feel the Perl Foundation should provide an appropriate grant for the documentation. The cost-benefit and intangible value to the Perl community is worth it. Mojo and great documentation could even possibly bring back some of the flock to the fold and make new converts to Perl.

Request and testimonial over. Mark S.

About TPF

The Perl Foundation - supporting the Perl community since 2000. Find out more at www.perlfoundation.org.

About this Entry

This page contains a single entry by Alberto Simões published on November 2, 2008 10:04 AM.

Frozen Perl 2009 is Coming was the previous entry in this blog.

2008Q4 Grant Proposal: The Perl Survey is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


OpenID accepted here Learn more about OpenID
Powered by Movable Type 6.2.2