- Why doesn't Mojolicious have any dependencies?
- Why reinvent wheels?
- What about backwards compatibility?
- What does the error "Maximum message size exceeded." mean?
- What does the error "Maximum line size exceeded." mean?
- Does Mojolicious run on Windows systems?
- Is it possible to run the builtin webserver on Windows?
- Whats the easiest way to install Mojolicious on UNIX?
- I think Mojolicious is awesome, how can i support you guys?
- I think i have found a bug, what should i do now?
- Which namespace should i use for Mojolicious plugins?
Mojolicious::Guides::FAQ - Frequently Asked Questions
This document contains the most frequently asked questions about Mojolicious together with the right answers.
We are optimizing Mojolicious for user-friendliness and development speed without compromises. While there are no rules in Mojolicious::Guides::CodingGuidelines that forbid dependencies, we do currently discourage adding non-optional ones in favor of a faster and more painless installation process. And we do in fact already use several optional CPAN modules such as IO::KQueue, IO::Epoll, IO::Socket::IP, IO::Socket::SSL, Net::Rendezvous::Publish and Plack to provide advanced functionality if they are installed.
Because we can make them rounder. Components specifically designed for user-friendliness and development speed are not easy to come by. While we are strong believers of the Perl mantra "There is more than one way to do it.", we also believe that well designed defaults result in a much more pleasant user experience. We want the best of both worlds.
In conformance with Mojolicious::Guides::CodingGuidelines, we will always deprecate a feature for at least one major release before removing or changing it in incompatible ways. New features can however be marked as experimental to explicitly exclude them from these rules. This gives us the necessary freedom to ensure a healthy future for Mojolicious. So, as long as you are not using anything marked experimental, untested or undocumented, you can always count on backwards compatibility, everything else would be considered a bug.
To protect your applications from excessively large requests and responses, our HTTP parser has a cap after which it will automatically stop accepting new data, and in most cases force the connection to be dropped. This limit is around
5MB by default, you can use the
MOJO_MAX_MESSAGE_SIZE environment variable or the
max_message_size attribute of Mojo::Message to change this value.
This is a very similar protection mechanism to the one described in the previous answer, but a little more specific. It limits the maximum length of any
\r\n terminated part of a HTTP message, such as request line, status line and headers. This limit is around
10KB by default, you can use the
MOJO_MAX_LINE_SIZE environment variable or the
max_line_size attribute of Mojo::Message to change this value.
Does Mojolicious run on Windows systems?
Sure it does! Right now there are two different ways of running Perl on the Windows platform. One is
Strawberry Perl and the other is
ActiveState Perl. Both are capable Perl distributions which are stable, mature and ready for production. But
Strawberry Perl is quite a bit better at dealing with the CPAN and especially XS based modules due to its remarkable toolchain. With it you can even install modules straight from the source as you would do on a Unix based machine.
It is! The builtin webserver is great way to run your Mojolicious web application on any platform. See Mojolicious::Guides::Cookbook for more information about running and deploying Mojolicious applications.
Note that if you run your application with the
--reload option Windows will lock your files. A simple Windows editor like
WordPad will complain that the file has already been opened by a different proccess. More capable editors can handle this accordingly and force the change.
Whats the easiest way to install Mojolicious on UNIX?
Quite possibly this oneliner.
sudo -s 'curl -L cpanmin.us | perl - Mojolicious'
I think Mojolicious is awesome, how can i support you guys?
Share your success story via blog or twitter, get more people hooked! :)
First make sure you are using the latest version of Mojolicious, it is quite likely that the bug has already been fixed. If that doesn't help prepare a test case demonstrating the bug, you are not expected to fix it yourself, but you'll have to make sure the developers can replicate your problem. Sending in your whole application generally does more harm than good, the
t directory of this distribution has many good examples for how to do it right. Writing a test is usually the hardest part of fixing a bug, so the better your test case the faster it can be fixed. ;)
If you decide to fix the bug yourself make sure to also take a look at Mojolicious::Guides::CodingGuidelines.
For all new plugins that you might want to release to CPAN we suggest using the "Mojolicious::Plugin" namespace. While "MojoX" has been used a lot in the past, it is now deprecated.