Wishlist thread (third edition)

[sri]

It's been almost a year since our last wishlist thread (https://groups.google.com/forum/#!searchin/mojolicious/wishlist/mojolicious/mIRRwNwDLSE/jw-7w48Z7E4J), so i think it is time for another round!

In this thread you can post changes or features you would like to see in Mojolicious, no rules, just say what's on your mind. ;)

P.S.: Quite a few of the features requested last time have actually been implemented in the meantime, like SOCKS5 support and non-blocking name resolution.

--

sebastian

[hertzhaft]

Hi sri,

here are my three wishes:

1. in a Mojolicious app, it would be nice to be able to run selected tests from the "t" directory more easily, like so:
  myapp test -v test3 test5

Currently I have to do
  myapp test -v ~/experiments/mojo/myapp/t/test3 ~/experiments/mojo/myapp/t/test5

Maybe Mojolicious::Command::test could first check for each argument if a file with that name exists in the t directory?

2. it would be nice if a Mojolicious app could display descriptions and usage on the command line for all Command packages in the app.
Currently it picks up only those that have their own files. My command packages are often so short that it's more handy to have them in the app file itself.

3. I work a lot with Mojo::Collections and find myself often writing code like "push @{$self->item->fields}, $something". I would suggest to add methods push, pop, unshift, shift and list to the module (which would operate on the collection and not create a new one). This way one could avoid the unwieldy array dereference and even chain the methods like this:
  $self->item->fields->push($something)->each(sub {...}).

The pop and shift methods would be useful when the collection contains objects with methods.
The list method should just return the dereferenced collection (like @$collection).
I know a similar proposal has been declined before, but I think it would make code more readable and more conform to the Mojo feel :-)

Love it!

Martin

[sri]

The pop and shift methods would be useful when the collection contains objects with methods.

The first/last methods seem more useful for method chains. ($dom->find('div')->last->text)

 

The list method should just return the dereferenced collection (like @$collection).

 

This already exists, you just call the each method without an argument. (my @elements = $dom->find('div')->each)

--

sebastian

[sri]

2. it would be nice if a Mojolicious app could display descriptions and usage on the command line for all Command packages in the app.
Currently it picks up only those that have their own files. My command packages are often so short that it's more handy to have them in the app file itself.

I don't think this is possible.

--

sebastian

[Ludwig Nussel]

sri wrote:
> It's been almost a year since our last wishlist thread
> (https://groups.google.com/forum/#!searchin/mojolicious/wishlist/mojolicious/mIRRwNwDLSE/jw-7w48Z7E4J),
> so i think it is time for another round!
>
> In this thread you can post changes or features you would like to see
> in Mojolicious, no rules, just say what's on your mind. ;)

My wish would be to allow storing secrets in the database :-)

https://groups.google.com/forum/#!searchin/mojolicious/secrets/mojolicious/5HraN26QGvo/7rp2EW6wiPkJ

cu
Ludwig

--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

[sri]

My wish would be to allow storing secrets in the database :-)

What is preventing that now? As far as i can see, you can just query the database during startup.

--

sebastian 

[olivier...@gmail.com]

Hello,

I wish there was an easy way to configure a "base_path" for Mojolicious without having to modify the application's code.

Today the only ways to modify the base_path is to use a before_dispatch hook or to use a plugin like M::P::RequestBase.

But when you are use a Mojo application from CPAN like mojopaste, you are not supposed to modify it. And anyway, a system administrator should not have to modify the application to deploy it the way he wants.

I think it would be great if we could set the base_path in the "listen" string like : listen => ['http://*/prefix:3000']

Or we could just add a "base_path" option.

Thanks!

[Luc didry]

+1 for a base_path feature !
--
Luc
http://www.fiat-tux.fr/
Internet n'est pas compliqué, Internet est ce que vous en faites.

[sri]

I think it would be great if we could set the base_path in the "listen" string like : listen => ['http://*/prefix:3000']

Or we could just add a "base_path" option.

This proposal ignores many problems, such as alternative deployment methods like PSG/CGI, and the inconsistency with the proxy option.

--

sebastian 

[Ben van Staveren]

I'd love to see a way where Mojolicious autoloads plugins if told to do so in configuration file or perhaps by naming convention. Given the request base thing, it'd solve that and let people perhaps solve that particular wish. I'd have use for it because I keep repeating the same boilerplate in my startup function that just loads plugins, be easier to run them out of a configuration file.

--
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 mojolicious...@googlegroups.com.
To post to this group, send email to mojol...@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Luc didry]

I would love a way to use a personnal boilerplate when generating a new app.

Something like this:
mojo generate app MyApp -b ~/.mojo/my_boilerplate

~/.mojo/my_boilerplate/ directory should be a mojo app, which name (let's say Boilerplate) would be replaced by the name of the generated app: lib/Boilerplate.pm would be renamed to lib/Myapp.pm, script/boilerplate to script/my_app and so on.

Maybe ~/.mojo could be a default directory, allowing to use the command like this:
mojo generate app MyApp -b my_boilerplate

And maybe you could still specify the whole path if you don't want to use ~/.mojo directory:
mojo generate app MyApp -b ~/mojo_boilerplate/boilerplate

[Olivier Duclos]

+1 for module auto-loading. That would be a very powerful feature.

> --
> You received this message because you are subscribed to a topic in the Google Groups "Mojolicious" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/mojolicious/hZu18SdEmbc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to mojolicious...@googlegroups.com.

[sri]

I'd love to see a way where Mojolicious autoloads plugins if told to do so in configuration file or perhaps by naming convention.

Sounds like something that can be easily prototyped on CPAN with a plugin.

--

sebastian 

[sri]

I would love a way to use a personnal boilerplate when generating a new app.

Also sounds like something that should be prototyped on CPAN with a plugin.

--

sebastian 

[hertzhaft]

Below is an example using Symbol::Table (which unfortunately is not in core).

Martin

- - 8< - - - - - - -
package Mojolicious::Command::task;
use Mojo::Base 'Mojolicious::Command';

has description => 'Run a task';
has usage       => "Usage: APPLICATION task [ARGS]\n";

sub run { shift->app->task(@_) };

package main;
use Symbol::Table;

my $package = "Mojolicious::Command";
my $st = Symbol::Table->New('PACKAGE', $package);
foreach my $subpkg (keys(%$st)) {
    print "Package $package contains commmand '$subpkg'\n";
    my $cmd = "${package}::$subpkg";
    print $cmd->new->usage;
    }

[Ben van Staveren]

True, but the idea would be to make all apps do it without having to explicitly code for it, but it would indeed make a suitable plug-in too

--

[sri]

2. it would be nice if a Mojolicious app could display descriptions and usage on the command line for all Command packages in the app.
Currently it picks up only those that have their own files. My command packages are often so short that it's more handy to have them in the app file itself.

And implemented. :)

    https://github.com/kraih/mojo/commit/9d6990627b7251adb98a3c8c25b27fe66f5cb979

--

sebastian 

[hertzhaft]

Wow, that was really fast! Thanks! I think this feature could be useful in other contexts, too.

What about my first wish, the tests? Any comment (not meaning to nag :-))?

Martin

[sri]

What about my first wish, the tests? Any comment (not meaning to nag :-))?

Very unlikely, the test command is really just meant as an example and even the documentation recommends the use of "prove".

--

sebastian

[sri]

True, but the idea would be to make all apps do it without having to explicitly code for it, but it would indeed make a suitable plug-in too.

This has been discussed on IRC today, and the only way to get it into Mojolicious core will be a very popular plugin on CPAN.

--

sebastian 

[Ben van Staveren]

guess I've got me a weekend project then :D

--

[Ludwig Nussel]

It's been a while since I investigated that issue. IIRC one of the
pitfalls was that one cannot run e.g. script/my_app help or
script/my_app test without an initialized and accessible database
anymore, even though both commands don't actually need a fully set
up app.

[b.du...@keele.ac.uk]

Not a feature, but I'd ask for something in the vein of Helmut's wish #1 and expand the documentation for a couple of deeply worked examples.  Still quite new to Mojolicious, I'm working my way through the docs to implement authenticated sessions for a site and would've appreciated something that packages all the pieces together: put authentication here, all authenticated routes go here, non-authenticated routes go over there, handle authentication failures and logouts this way and implement mixed http/https calls like so.  If this was one chapter in a book, I'd buy the whole thing just for that as I have this feeling that I'm still missing something either conceptually or in code.

The quality of the documentation is such that I've been able to get this far without resorting to the mailing list, something that I maybe should have done earlier.

best,
Boyd

[sri]

If this was one chapter in a book, I'd buy the whole thing just for that as I have this feeling that I'm still missing something either conceptually or in code.

Not a day goes by where someone doesn't ask for a Mojolicious book, sadly we are still lacking an author.

--

sebastian 

[Roger Crew]

could we maybe have a generic [hmac_]sha_foo in Mojo::ByteStream and

Mojo::Util that always points to the currently Best Known [Keyed] Hash,

rather than hardwiring SHA1 into everything -- and in particular having it be
the only choice for signed cookies and session keys -- which makes me a bit nervous

seeing as we're really all supposed to be using SHA256 by now.

(and so that whenever it is in the next 5-10 years that something bad 

turns up in SHA2, we'll be ready to swap in SHA3)

[sri]

rather than hardwiring SHA1 into everything -- and in particular having it be

the only choice for signed cookies and session keys -- which makes me a bit nervous

seeing as we're really all supposed to be using SHA256 by now.

Since when is HMAC-SHA1 a problem? Did i miss any new research?

--

sebastian 

[Viktor Nacht]

Rerequest for a way to set a custom error class name to override field-with-error in TagHelpers. I believe this has been rejected before. :) - V

[Ben van Staveren]

Small wish: the ability to see if a plug-in has been loaded (eg $self->has_plugin(...) or something similar)

On Jun 18, 2015 8:34 AM, "Viktor Nacht" <viktor...@gmail.com> wrote:

Rerequest for a way to set a custom error class name to override field-with-error in TagHelpers. I believe this has been rejected before. :) - V

--

[sri]

Small wish: the ability to see if a plug-in has been loaded (eg $self->has_plugin(...) or something similar)

Brings back the old question of what problem this would actually solve? If you depend on a certain helper, can't you just check for that? What about plugins that get loaded multiple times, like Mojolicious::Plugin::Mount?

--

sebastian 

[Helmut Wollmersdorfer]

I strongly agree with sri in this problem. In practice this leads to unsolvable problems, especially across different deployment platforms.

Been there, tried this, wasted time.

 

[sri]

Rerequest for a way to set a custom error class name to override field-with-error in TagHelpers.

Is there an actual use case?

--

sebastian 

[Luc didry]

Yes: using the error class from twitter bootstrap (or any other css framework).

I agree with Ben, it could be really useful.

[sri]

Yes: using the error class from twitter bootstrap (or any other css framework).

And you can't do that by redefining the tag_with_error helper?

--

sebastian 

[Ben van Staveren]

For an autoload-bunch-of-plugins plugin it's sort of essential to avoid loading things multiple times if not needed, thats kind of the only reason I'd want it.

--

[Stefan Adams]

On Wed, Jun 17, 2015 at 6:58 AM, <b.du...@keele.ac.uk> wrote:

expand the documentation for a couple of deeply worked examples.  Still quite new to Mojolicious, I'm working my way through the docs to implement authenticated sessions for a site and would've appreciated something that packages all the pieces together: put authentication here, all authenticated routes go here, non-authenticated routes go over there, handle authentication failures and logouts this way and implement mixed http/https calls like so.

I second this!  The Blog example of Mojo::Pg is really awesome.  We just used it to build a replacement for Google Moderator (since it's shutting down in two weeks)!

It would be great to have the simple blog example be expanded to have an Ajax interface that did not do a page refresh for each action, use non-blocking form in the Mojo::Pg models, and have a simple authentication system with authorization requirements for specific routes.

Just like with the blog example, each of the additional examples wouldn't need to be much, just enough to demonstrate best practices.

[Stefan Adams]

On Thu, Jun 18, 2015 at 10:02 AM, Stefan Adams <s103...@gmail.com> wrote:

It would be great to have the simple blog example be expanded to have an Ajax interface that did not do a page refresh for each action, use non-blocking form in the Mojo::Pg models, and have a simple authentication system with authorization requirements for specific routes.

Just like with the blog example, each of the additional examples wouldn't need to be much, just enough to demonstrate best practices.

Additionally, it would be great for this enhanced example app to also have a full suite of tests.

I can understand that you wouldn't want to include such an example app in Mojolicious core because of the unmet dependencies (such as Mojo::Pg).  Perhaps a separate project repo whose sole purpose is to tie all these things (Mojolicious, Mojo::Pg, Minion) together and include a few additional routine bells and whistles like auth/authz, websockets, non-blocking database model, ajax user interface, etc and have a suite of tests to make the whole thing test-driven!

I would buy another limited edition shirt.  Probably even a couple!  :D

[sri]

It would be great to have the simple blog example be expanded to have an Ajax interface that did not do a page refresh for each action, use non-blocking form in the Mojo::Pg models, and have a simple authentication system with authorization requirements for specific routes.

It's very unlikely that i'll be able to make more example apps, but anyone here is welcome to fork and extend the existing ones.

--

sebastian 

[Stefan Adams]

I'm not sure if this is something that makes sense to include in core as I don't know much about it, but I hope it doesn't hurt to ask...

Websockets are built in to mojolicious and available out of the box. Would it be possible and in line with project mission to do something similar for WebRTC?

--

[sri]

Would it be possible and in line with project mission to do something similar for WebRTC?

WebRTC is crazy complicated, so even if we wanted to do it, i doubt we currently have the resources.

--

sebastian 

[sri]

WebRTC is crazy complicated, so even if we wanted to do it, i doubt we currently have the resources.

Same problem we already have with HTTP/2 actually.

--

sebastian 

[Roger Crew]

well, this came out today, though I'll grant it's only a somewhat more dire version of what Bruce Schneier was saying 4 years ago,

and yes I get that HMAC is different
(and maybe even HMAC-MD5 is still safe even if I wouldn't want to bet the farm on it 10 years from now),

but you do have a number of places using unadorned SHA1
(including one where I'm really not sure why you're not using HMAC 
see DefaultHelpers::_csrf_token)

and it seems to me if you genericize (use "...sha_sum" everywhere, point it to whatever is best-practice these days, let overly paranoid folks like me bump it up to SHA3 in the config file if we want) then you're basically done with this forever (ha ha...)

[sri]

but you do have a number of places using unadorned SHA1
(including one where I'm really not sure why you're not using HMAC 
see DefaultHelpers::_csrf_token)

The CSRF token just needs to be a reasonably random value, the hash algorithm is irrelevant.

--

sebastian 

[Roger Crew]

The CSRF token needs to be unguessable by an attacker.  
steady_time() is little more than a counter and rand() shouldn't really be relied on to be unguessable either.  
Which, I assume, is why you're prepending a secret key and hashing the result.

But this is exactly the problem that HMAC is intended to solve

  hmac_sha1_sum ( steady_time . rand(999), $c->app->secrets->[0] )

then no one has to worry about padding oracle attacks or any of that shit..)