One of Catalyst's biggest strengths has also been one of it's biggest weaknesses for quite some time now.
The Catalyst::Engine modules are bindings to countless third party modules that allow you to run Catalyst on all kinds of servers.
Sadly these bindings are mostly just patchwork with all kinds of side effects.
You can't really blame the Catalyst developers for this because there are currently no better options available.
Especially LWP is not very good on the server side, even though it is an awesome client library.
This is where Mojo comes to the rescue, it provides basically everything below the dispatcher layer in a simple and reusable form.
You could call it a runtime environement for Perl web frameworks.
package MyApp;
use strict;
use warnings;
use base 'Mojo';
sub handler {
my ($self, $transaction) = @_;
my $response = $transaction->response;
$response->code(200);
$response->headers->content_type('text/plain');
$response->body('Hello World!');
return $transaction;
}
1;
As you can see, there is no dispatcher at all in Mojo, all you get is a handler method in your application class, similar to mod_perl.The Mojo core distribution contains four high quality server bindings that have been designed and rewritten from scratch, CGI, FastCGI, Daemon and Prefork Daemon.
All bindings are pure-Perl for portability reasons and have not a single prereq!
The next major release of Catalyst could already be running on Mojo, but i'll leave the final decision to the current Catalyst developers.
This was naturally just the tip of the iceberg, Mojo contains a full HTTP 1.1 stack and much more, but you should get the idea of what it's all about. :)
More about the individual Mojo components in my next article.
Hi,
how does this compare to HTTP::Engine?
Thanks
What HTTP::Engine has going for it now is a more robust HTTP response abstraction, including an upload() method. I don't see an upload() method in Mojo currently.
What Mojo has going for it is *no dependencies*. When I tried to install HTTP::Engine, it brought with it literally over 200 Perl modules as dependencies. I want neither the complexity nor the performance hit that goes along with that dependency chain.
I don't think the dependency change is easy for HTTP::Engine to change. On the other hand, while Mojo is missing some methods now, they seem like they could be easily adapted from other open source implementations already on CPAN
On the surface both might look a bit alike.
But HTTP::Engine seems to be focused on abstraction of current third party libraries (which pretty much suck), while Mojo implements a complete HTTP 1.1 stack all by itself.
Mojo has no prereqs besides Perl 5.8. ;)
My highest priority atm. is RFC compliance, no idea what HTTP::Engine is aiming for.
I have to disagree, if you take a closer look at Mojo you'll notice that it's response abstraction is far superior.
Mojo::Message and associated modules were specifically designed to be able to parse, represent and generate everything in RFC2616. (MultiPart building for example is easier than ever before)
Just take a look at message.t
About uploads() you are right, i've not yet implemented it because i'm thinking about a more userfirendly alternative.
But all you need to implement it is already in place, should be about 10 lines of code to add. :)
It's hard for me to see how Mojo is far superior here when it lacks even a basic "param()" method. It looks like a lower level library at this point.
Perhaps what remains is considered just "easy coding and documentation", but that's how I see the current state things.
I remain interested in Mojo as a potential abstraction layer over CGI and FastCGI. Are mod_perl server components also plained? It does seem like someone else could plug them in easily, even if you aren't interested in them yourself.
The sugar coating will be implemeted as soon as i'm sure how it should look like. :)
I'm building a first example framework right now, so that shouldn't be too far away.
Yes, a mod_perl server component would be quite easy to write.
Btw. I have a working high perfromance prefork FastCGI server component, just need to clean it up a bit for release.