Talking points for Mojoconf 2014

[sri]

I'll post some things in this thread i think we might want to talk about at Mojoconf, and possibly make decisions about while we are all at the same physical location.

1) HTTP/2 support. Where do we start? How far do we want to go?

2) New Perl 5 features (such as subroutine signatures). How are we going to support them? Which versions of Perl 5 are we going to support in the future?

3) Promises instead of continuation-passing style for non-blocking APIs. Does it make sense? Is it the future? How would it look like?

4) Perl 6 support. At which point would an official port make sense? What would Mojolicious look like designed for proper parallelism?

Feel free to add yours, i'll be available for all kinds of discussions... in exchange for beer. :)

--

sebastian

[sri]

5) Redesign of Mojolicious::Controller::param() to get rid of the list context attack vector. What can we do? How would it affect similar APIs like Mojolicious::Validator::Validation::param()?

--

sebastian

[Vincent HETRU]

Hi Sebastian,

Here some talk suggestions

6) Is it planned for mojolicious to be backed by a company in the near-future to offer paid support and training for company using it and to promote mojolicious? If not what's the evil plan behind mojolicious then?

7) The more I'm using mojolicious and the more I think we need another tutorial, not to replace the official one which is really good but an additional one that would go step by step to build a typical real-time application. 

Something more like what sensio labs did with symfony 1.4 or the angularjs one 

A true step by step tuto that would be maintained with the latest version of mojolicious and available for download from github for example. Something a complete newbie could start with quickly to grab the power of mojolicious for real time web app. I'm thinking about something like an online chat or like mojomber https://github.com/vti/mojomber. I would be glad to start something like that and have plenty of ideas. But I'd need some help to make sure I apply the best practice as I'm still pretty new to Perl and as well to implement a pub/sub message bus for app workers to communicate which I failed to implement so far.

I'm pretty sure that just with these 2 topics we can have enough to talk for a few beers

Cheers

Vincent

[sri]

Something more like what sensio labs did with symfony 1.4

Not a day goes by where someone doesn't ask for a Mojolicious book, we are in desperate need of one.

--

sebastian 

[sri]

3) Promises instead of continuation-passing style for non-blocking APIs. Does it make sense? Is it the future? How would it look like?

In case it's not clear how this is a problem... most of our blocking/non-blocking hybrid methods take an optional CODE reference as last argument for switching between modes.

  # Blocking

  my $tx = $ua->get('mojolicio.us');

  # Non-blocking

  $ua->get('mojolicio.us' => sub {

    my ($ua, $tx) = @_;

  });

So there is not much room in the API for passing around promises, and they would most likely need their own methods.

  # Blocking

  my $tx = $ua->get('mojolicio.us');

  # Non-blocking

  $ua->aget('mojolicio.us')->then(sub {

    my $tx = shift;

  });

Another interesting question is where this would leave modules like Mojo::EventEmitter and callbacks that get invoked multiple times, Perl6 has this interesting concept of "Supplies". (http://perlcabal.org/syn/S17.html#Supplies)

  $ua->on('error')->tap(sub {

    my $err = shift;

  });

  Mojo::IOLoop->listen(port => 3000)->tap(sub {

    my $stream = shift;

  });

Perl6 uses Promises very extensively, so this is going to be an important topic for a Mojolicious port too. (http://perlcabal.org/syn/S17.html#Promises)

--

sebastian

[sri]

A fun example for promises vs. supply are timers.

  # Promise

  my $promise = Mojo::IOLoop->timer(5);

  $promise->then(sub { say '5 seconds later.' });

  # Supply

  my $supply = Mojo::IOLoop->recurring(5);

  $supply->tap(sub { say 'Another 5 seconds later.' });

--

sebastian

[Alexander Karelas]

One could set the "blockingness" of $ua as a parameter during $ua's
creation.

Unless there's a use case for mixed "blocking" and "non-blocking"
behaviour coming from a single $ua object.

Not sure this is the right place to discuss this topic... apologies if not.

[sri]

Unless there's a use case for mixed "blocking" and "non-blocking" 

behaviour coming from a single $ua object.

I'm afraid there are use cases for it, Minion for example needs it to emulate a running worker for the test features. (Jobs may be enqueued non-blocking, while workers only use blocking operations...)

 

Not sure this is the right place to discuss this topic... apologies if not.

It's fine.

--

sebastian 

[sri]

2) New Perl 5 features (such as subroutine signatures). How are we going to support them? Which versions of Perl 5 are we going to support in the future?

I believe this one will be a very important topic during Mojoconf, and specifically how we are going to deal with the new subroutine signatures in Perl 5.20.

  use Mojolicious::Lite;

  get '/' => sub ($self) {

    $self->ua->get('mojolicio.us' => sub ($ua, $tx) {

      $self->render(text => $tx->res->dom->at('title')->text);

    });

  };

  app->start;

--

sebastian

[sri]

Preliminary tests with Promises have been catastrophic, once you start chaining things together it's nearly impossible to avoid cycles.

    http://pastie.org/9106756

Starting to get the feeling that Perl and Promises don't mix.

--

sebastian

[Alexander Karelas]

Maybe we should contact Stevan Little, the creator of Promises, about it.

[sri]

Maybe we should contact Stevan Little, the creator of Promises, about it.

Already talking to him, and so far we agree that it's a conceptual problem with Perl garbage collection (or lack thereof).

    http://pastie.org/9106784

Our delays are affected too, but we can mitigate the problem by passing along the invocant.

--

sebastian

[sri]

Preliminary tests with Promises have been catastrophic...

Quick update, after further research i've found a way to make it work, inside-out objects. Preliminary test results have been so good that inside-out storage has already been added as a feature to Mojo::IOLoop::Delay. It basically works as a protective fence around your closures and prevents circular references.

    https://github.com/kraih/mojo/commit/0caa9135ae85f6a413fe0483e526e69e7e808ba3#diff-892d699369fe9beca14818a2019adc36R10

This could be adapted for inside-out promises, so you never have to worry about "weaken" ever again.

--

sebastian

[sri]

Quick update, after further research i've found a way to make it work, inside-out objects.

And here's an actual prototype for a promise class.

    https://gist.github.com/kraih/11328864

The only problem now is that to use promises effectively we would have to make breaking changes to basically every API in mojolicious that currently accepts callbacks. Of course not having to worry about circular references and weaken at all is quite an upside. This needs to be discussed in the community.

--

sebastian 

[Helmut Wollmersdorfer]

Am Montag, 17. März 2014 23:53:22 UTC+1 schrieb sri:

2) New Perl 5 features (such as subroutine signatures). How are we going to support them? Which versions of Perl 5 are we going to support in the future?

I am still running Perl 5.10.1 on some dozens of production machines. Next will be the version of the current Debian stable: Perl 5.14.2.

If Mojolicious will break backwards compatibility then it would be necessary to maintain two branches.

 

4) Perl 6 support. At which point would an official port make sense? What would Mojolicious look like designed for proper parallelism?

When Perl 6 reaches the critical mass of usage in production (performance, stability, community, available modules). 

[sri]

I am still running Perl 5.10.1 on some dozens of production machines. Next will be the version of the current Debian stable: Perl 5.14.2.

Aside from the fact that using a system Perl for deployment is a bad idea in general, such a branch already exists. https://github.com/jamadam/mojo-legacy

--

sebastian 

[Neil Watson]

On Tue, Apr 29, 2014 at 05:03:00AM -0700, sri wrote:
> I am still running Perl 5.10.1 on some dozens of production machines.
> Next will be the version of the current Debian stable: Perl 5.14.2.
>
> Aside from the fact that using a system Perl for deployment is a bad

Could someone please explain that statement?

--
Neil Watson
Linux/UNIX Consultant
http://watson-wilson.ca

[sri]

>   Aside from the fact that using a system Perl for deployment is a bad

Could someone please explain that statement?

For more reasons than i can count...

    a) System Perl is usually very very old and not maintained by the community anymore, so you miss out on many important bug fixes (http://perldoc.perl.org/perlpolicy.html#MAINTENANCE-AND-SUPPORT)

    b) System Perl is always broken in some way or another, RHEL for example removes very very important core modules like Scalar::Util.

    c) Most distributions compile their Perl with options like ithreads, which make your applications a lot slower than they have to be.

    d) You can't update modules from CPAN, because of conflicts with packages installed by your distribution. (missing out on bug fixes again)

    e) Old old old modules in the package system... Debian stable for example seems to still ship IO::Socket::SSL 1.76, which uses bad cipher lists and doesn't support perfect forward secrecy. (oh, and Mojolicious 2.98... hahahahahaha... *sob*)

Personally, at this point i pretty much avoid trying to help folks that are obviously using a system Perl, because it's just too much trouble. (if you know how to use the tools necessary to make it work, such as local::lib, you'd most likely not need my help in the first place)

--

sebastian

[Neil Watson]

On Tue, Apr 29, 2014 at 05:55:26AM -0700, sri wrote:
> Personally, at this point i pretty much avoid trying to help folks that
> are obviously using a system Perl, because it's just too much trouble.
> (if you know how to use the tools necessary to make it work, such as
> local::lib, you'd most likely not need my help in the first place)

Are you suggesting that to deploy a Mojo app one should also deploy
a custom Perl build? And the spend many extra hours maintaining it?

[sri]

Are you suggesting that to deploy a Mojo app one should also deploy
a custom Perl build? And the spend many extra hours maintaining it?

It's a different tradeoff, not a new cost. We live in the age of docker, perlbrew and carton.

--

sebastian 

[Joe Landman]

On 04/29/2014 09:06 AM, Neil Watson wrote:
> On Tue, Apr 29, 2014 at 05:55:26AM -0700, sri wrote:
>> Personally, at this point i pretty much avoid trying to help folks
>> that
>> are obviously using a system Perl, because it's just too much trouble.
>> (if you know how to use the tools necessary to make it work, such as
>> local::lib, you'd most likely not need my help in the first place)
>
> Are you suggesting that to deploy a Mojo app one should also deploy
> a custom Perl build? And the spend many extra hours maintaining it?
>

Hmm ... we defensively deploy our own Perl that gets built as part of
our tool chain, with Mojolicious and a number of other modules installed
as part of it. If you don't want to build your own build system,
Perl::brew is the way to go. See http://perlbrew.pl/

You *can* run it against the distro version, but in almost all cases,
for all languages, this is strongly counter-indicated/dis-recommended.

For example: The Perl in RHEL/CentOS 6 has been EOL since 2009. 5
years. See http://cpan.scalableinformatics.com/src/README.html for more
info. Many many bugfixes and improvements, not simply to the core, but
to the modules around it.

SRI noted some of the reasons. We build our own, quite defensively,
after a long battle trying to make the distro set of Perl's do what we
need. If you change the core distro Perl in any way, it is possible you
will, unwittingly, break an application that *depends* upon the buggy
feature/misfeature to work. We've had this happen so many times, that
we simply gave up on trying to fix it, and built our own.

FWIW: The exact same issue exists with Python, Ruby, R, Octave, ...

[Helmut Wollmersdorfer]

Am Dienstag, 29. April 2014 14:03:00 UTC+2 schrieb sri:

I am still running Perl 5.10.1 on some dozens of production machines. Next will be the version of the current Debian stable: Perl 5.14.2.

Aside from the fact that using a system Perl for deployment is a bad idea in general, such a branch already exists. https://github.com/jamadam/mojo-legacy

mojo-legacy is for Perl 5.8.x.

The current Mojo runs fine on 5.10.1.

Back to the topic: What are the costs, risks and the benefits of e.g. converting the code of Mojolicious to modern features of Perl not backwards compatible to e.g. Perl 5.14.x?

[sri]

The current Mojo runs fine on 5.10.1.

We already do not *fully* support anything below Perl 5.16, while all tests still pass, we do not go out of our way to work around bugs such as the infamous $@ flaw before 5.14.

    http://mojolicio.us/perldoc/Mojolicious/Guides/FAQ#Which_versions_of_Perl_are_supported_by_Mojolicious

--

sebastian