On 01/02/2014 12:59 AM, sri wrote:
Happy new year everyone!
2013 has been a great year for Mojolicious and we've made a lot of
progress, lets start 2014 by trying something new.
In this thread you can post changes or features you would like to see in
Mojolicious, no rules, just blurt away. :)
P.S.: Our official roadmap can be found on
GitHub. https://github.com/kraih/mojo/issues?labels=future&state=open
A few things on the wishlist:
1) Long standing (but minor) annoyance I'd love to see addressed.
All the Mojo* scripts seem to use '/usr/bin/env perl' in their header.
This is true regardless of which perl we use to build them. As we have
our own out-of-distro perl we use for our apps, residing in its own
tree, I have to manually change every instance of this in all the
mojolicious/mango/... code to point back to our perl.
Setting a path environment is a non-starter ... a really good way to
break a distribution is to replace their core bits with the bits you
need. Getting the distribution to fix their perl, and use something
which hasn't been EOL for 3+ years is well ... its CentOS, which is
built off of Red Hat, whom think 5.10.x is shiny and new.
Basically, it would save us time at each new Mojo* update if the
build/make code picked up the path of the perl binary used to build it.
FWIW, I'd be happy to contribute patch(es) to this effort if this is
something you'd consider.
2) This is going to sound strange/too-simple/...
I'd love there to be a very basic framework/scaffold of an application
(::Lite is fine/preferred) that has authentication built up correctly.
Why this is important to me: I look at authentication as boilerplate
stuff that I don't want to write. I want something that just works (not
unlike Mojo*), that I can build upon.
Yeah, I know the counter arguments: every login system is different,
everything for logins should be custom.
But I think there is enough commonality that a simple pattern could be
supplied. Basically I look at Mojo* as a best practice system we build
our apps upon, and I'd like to leverage best practice login technologies
without having to go through the joy of coding our own (and finding bugs
to fix, etc.) as compared to spending time on the app itself.
This might be better addressed with a Mojolicious::Plugin::Login thing,
and I'm even happy to take a stab at starting this.
3) More important: SSL docs/examples ... Maybe I missed this, but I'd
like it to be more prominent. I tend to front the Mojo apps on the
interwebs with nginx, but for our internal (not exposed to the evil
interwebs) apps, I still want SSL if at all possible.
--
sebastian
--
You received this message because you are subscribed to the Google
Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
