Hi,
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.
clayton.scott.myopenid.com:
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.
Fine.
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.