[Mojolicious] New D-Bus module for Mojolicious

2019-11-19 Thread Felipe Gasper
Hi all,

CPAN’s Protocol::DBus now includes a connector for Mojolicious, 
Protocol::DBus::Client::Mojo.

Hope it’s useful!

cheers,
-Felipe Gasper (FELIPE)

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/20c6d897-d65c-4868-8e6b-c31fcd834b35%40googlegroups.com.


[Mojolicious] libcurl via Mojolicious

2019-12-10 Thread Felipe Gasper
Hi all,

I’ve got a library called Net::Curl::Promiser that does the “dirty-work” of 
interfacing between different event loops and Net::Curl::Multi. I recently 
added a Mojo::IOLoop backend, so it should now be possible to integrate 
libcurl seamlessly into Mojolicious via Net::Curl::Promiser::Mojo.

Hope it’s useful … enjoy!

-FG

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/856af456-b0d4-4638-9eca-9661f02bb555%40googlegroups.com.


Re: [Mojolicious] libcurl via Mojolicious

2019-12-10 Thread Felipe Gasper
Hi Stefan,

The primary advantage I see is that whatever libcurl features that 
Net::Curl exposes are now readily usable within Mojo. So libcurl’s http/2 
support, for example, should be usable, as would non-HTTP protocols that 
libcurl supports like FTP, IMAP, etc. (Possibly even the experimental http/3 
support?)

Other potential advantages would be speed (XS/C versus pure Perl) and, 
I would think, wider use: as much as Mojo is used in Perl, curl is used 
practically everywhere, with bindings in Python, Ruby, Rust, etc.

The disadvantage is that you’ll need to use Net::Curl::Easy, which 
isn’t a very Perlish interface. HTTP::AnyUA’s backend for same demonstrates how 
to “tame the beast”, though, and Net::Curl’s own documentation is quite helpful 
(IMO), so there’s at least copious prior art to reference.

I should disclaim here: I’ve not benchmarked this nor used it very 
extensively beyond just verifying that it works for simple parallel GETs. That 
said, since Net::Curl::Promiser is fairly simple, and Net::Curl itself has been 
around for a while and remains actively maintained, whatever gremlins may still 
lurk should be easy to find and fix.

-FG


> Le 10 déc. 2019 à 13:19, Stefan Adams  a écrit :
> 
> Hi, Felipe! Thanks for sharing this! What advantages does integrating with 
> libcurl have over using Mojo::UserAgent?
> 
> On Tue, Dec 10, 2019, 8:41 AM Felipe Gasper  wrote:
> Hi all,
> 
> I’ve got a library called Net::Curl::Promiser that does the “dirty-work” of 
> interfacing between different event loops and Net::Curl::Multi. I recently 
> added a Mojo::IOLoop backend, so it should now be possible to integrate 
> libcurl seamlessly into Mojolicious via Net::Curl::Promiser::Mojo.
> 
> Hope it’s useful … enjoy!
> 
> -FG
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/856af456-b0d4-4638-9eca-9661f02bb555%40googlegroups.com.
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFTQyKHHKe1OLaCkfxdN%2B-SgkKtbMq18q93w8FOFdKox0A%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/9966E38E-4539-409D-AF31-C2397EBED4A7%40felipegasper.com.


Re: [Mojolicious] libcurl via Mojolicious

2019-12-10 Thread Felipe Gasper



> Le 10 déc. 2019 à 13:57, sri  a écrit :
> 
> The disadvantage is that you’ll need to use Net::Curl::Easy, which 
> isn’t a very Perlish interface. HTTP::AnyUA’s backend for same demonstrates 
> how to “tame the beast”, though, and Net::Curl’s own documentation is quite 
> helpful (IMO), so there’s at least copious prior art to reference. 
> 
> Another big disadvantage is that it doesn't use Mojo::Promise. I don't think 
> it will attract too many Mojo users without.

The latest version does, actually.

-FG

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/E314D59E-D507-4C58-94E6-BF7B06D847AF%40felipegasper.com.


Re: [Mojolicious] libcurl via Mojolicious

2019-12-10 Thread Felipe Gasper



> Le 10 déc. 2019 à 14:08, Sebastian Riedel  a écrit :
> 
>>> Another big disadvantage is that it doesn't use Mojo::Promise. I don't 
>>> think it will attract too many Mojo users without.
>> 
>> The latest version does, actually.
> 
> Ah, nice. Then you can simplify your example too.
> 
>my $promiser = Net::Curl::Promiser::Mojo->new();
> 
>my $handle = Net::Curl::Easy->new();
>$handle->setopt(CURLOPT_URL() => $url);
> 
>$promiser->add_handle($handle)->then(
>  sub { print "$url completed.$/" },
>  sub { warn "$url failed: " . shift },
>)->wait;
> 
> And if you really want to conform to the Mojo style you rename
> add_handle to add_handle_p, because we like to make promise
> returning methods obvious. ;)

Ah, a nice convention!

I’ll add an “add_handle_p()” alias, update the example, and make another 
release.

-F

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/EA07C296-B400-4E3D-8DA3-DD8CFF5247D1%40felipegasper.com.


Re: [Mojolicious] Websocket cat

2019-12-15 Thread Felipe Gasper
I’ve spent very little time with Mojo as a WS client, but I found the example 
in Mojo::UserAgent’s documentation to be enough to get me where I needed to go.

=
$ua->websocket('ws+unix://%2Ftmp%2Fmyapp.sock/echo.json' => sub {
  my ($ua, $tx) = @_;
  say 'WebSocket handshake failed!' and return unless $tx->is_websocket;
  $tx->on(json => sub {
my ($tx, $hash) = @_;
say "WebSocket message via JSON: $hash->{msg}";
$tx->finish;
  });
  $tx->send({json => {msg => 'Hello World!'}});
});
Mojo::IOLoop->start unless Mojo::IOLoop->is_running;
=

^^ So, specify remote server and port in the wss:// URL.

-FG


> On Dec 15, 2019, at 11:38 AM, John  wrote:
> 
> I am trying to get my head around using mojolicious as a websocket client.  I 
> have used it as a websocket server in various projects.   To start I wanted 
> to create a simple command line utility that connected to a websocket server 
> and printed the json it received.
> 
> I began with the documentation:
> 
> https://mojolicious.org/perldoc/Mojo/IOLoop/Stream/WebSocketClient
> 
> Due to my lack of understanding the basics a couple things confuse me.   
> Where do I specify the remote server/port and how do I define $handle?   My 
> code is pretty much the example at that location but with "use 
> warnings/strict" added.I haven't been able to get an understanding based 
> on my review of the docs.
> 
> It would be great to see an example as I expect others have done this before. 
>   Otherwise some pointers wold be appreciated.
> 
> Thanks,
> 
> John
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/cc400d5f-e7e2-1595-70e5-94ff1974eb27%40tonebridge.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/052B04A6-DAB2-4412-9F1A-4C935D1CD263%40felipegasper.com.


[Mojolicious] XS backend for Mojo::Promise?

2019-12-26 Thread Felipe Gasper
Hi all,

I’ve been at work on refactoring CPAN’s AnyEvent::XSPromises to be 
usable by event interfaces other than AnyEvent. What I have isn’t yet ready for 
release but is getting close:

https://github.com/FGasper/p5-Promise-XS

In tandem with this I’ve been updating Promise::ES6 to use the new XS 
code as an implementation when available.

I don’t know Mojo well enough to be at ease with doing the work, but if 
anyone’s interested, it might make a nice improvement in Mojo to have XS-backed 
promises when available.

-Felipe Gasper
Mississauga, Ontario

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/3DB22183-8059-44EA-8AEF-30D84CA70839%40felipegasper.com.


Re: [Mojolicious] mojo async/await with controller

2020-01-10 Thread Felipe Gasper
I’m just encountering Mojo::AsyncAwait and notice that it lists Coro as a 
dependency.

Isn’t Coro problematic in newer Perls? I thought Marc had basically written off 
support for 5.22 onward.

-F


> On Jan 10, 2020, at 8:49 AM, 'Tobias Oetiker' via Mojolicious 
>  wrote:
> 
> I just read Joel's blog 
> (https://mojolicious.io/blog/2018/12/24/async-await-the-mojo-way/) about 
> async/await support. This is wonderful. I am totally excited about this. 
> Thank you to all involved!
> 
> Obviously I had to test this right away and it works great with the 
> Mojolicious::Lite demo shown in the blog. 
> 
> But how do I specify a route to a async method in a controller for a 
> Mojolicious app?
> 
> Using a callback I can easily translate the Lite approach
> 
> $r->get('/cb' => async sub ($c) {
> await Mojo::Promise->new(sub ($resolve,$fail) {
>   Mojo::IOLoop->timer(3 => sub { 
>   $resolve->();
>   });
> });
> $c->render(text => 'hello');
> });
> 
> but how do I use this when I want to have the code in a controller:
> 
> $r->get('/ctr')->to('example#hello');
> 
> with
> 
> package MyApp::Controller::Example;
> use Mojo::Base 'Mojolicious::Controller', -async, -signatures;
> 
> async sub welcome ($self) {
>   await Mojo::Promise->new(sub ($resolve,$fail) {
>   Mojo::IOLoop->timer(3 => sub { 
>   $resolve->();
>   });
>   });
>   $self->render(text => 'hello');
> }
> 
> does not work as expected as the router does not seem to expect the methods 
> to be async when called like that.
> 
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/519ec59d-cb9d-46c6-9a6a-970a2f3142b6%40googlegroups.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/DDE13127-6F00-48CF-A5EF-DB91849080B5%40felipegasper.com.


[Mojolicious] Test::Mojo to test WS client?

2020-01-22 Thread Felipe Gasper
Hello,

I see t/mojolicious/websocket_lite_app.t in the Mojolicious 
distribution, but this seems to test Mojo as a WS server. Are there any 
examples of using Test::Mojo--or any other tool--to test Mojo-powered WS 
clients?

Thank you!

-FG

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/80877B50-2AD9-4C15-9410-52D74C104161%40felipegasper.com.


Re: [Mojolicious] Test::Mojo to test WS client?

2020-01-22 Thread Felipe Gasper
Hi Dan,

Thank you for your response!

So, maybe what I need isn’t Test::Mojo. I have:

-
package t::MockApp;

use Mojo::Base -strict;

use Mojolicious::Lite;

websocket '/my-websocket-endpoint' => sub { ... }
-

… and I’d like my tested $ua (Mojo::UserAgent->new()) to call logic 
defined in t::MockApp, rather than going out to the real world. I’d also like 
to define other mock server classes and have other parts of the test use those 
classes instead.

I’ve tried “$ua->server->app($TEST_MOJO_APP) if $TEST_MOJO_APP” in my 
tested code, but that doesn’t seem to work. (The client times out rather than 
connecting to my WS server logic.)


-FG


> On Jan 22, 2020, at 10:40 AM, Dan Book  wrote:
> 
> You mentioned using Test::Mojo - the test file you mentioned does this, it 
> tests both client and server.
> 
> -Dan
> 
> On Wed, Jan 22, 2020 at 10:38 AM Dan Book  wrote:
> https://github.com/mojolicious/mojo/blob/master/t/mojo/websocket.t 
> 
> -Dan 
> 
> On Wed, Jan 22, 2020 at 10:34 AM Felipe Gasper  
> wrote:
> Hello,
> 
> I see t/mojolicious/websocket_lite_app.t in the Mojolicious 
> distribution, but this seems to test Mojo as a WS server. Are there any 
> examples of using Test::Mojo--or any other tool--to test Mojo-powered WS 
> clients?
> 
> Thank you!
> 
> -FG
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/80877B50-2AD9-4C15-9410-52D74C104161%40felipegasper.com.
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/CABMkAVVE1dvq-wv5HqTcXDExqUpOa4_%3DsZCZDh%3DZ7zJGvwDs4Q%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/1AADCC7B-E06A-49F5-9B4D-4BEB4FD4D46C%40felipegasper.com.


Re: [Mojolicious] Test::Mojo to test WS client?

2020-01-22 Thread Felipe Gasper


> On Jan 22, 2020, at 12:25 PM, Felipe Gasper  wrote:
> 
> Hi Dan,
> 
>   Thank you for your response!
> 
>   So, maybe what I need isn’t Test::Mojo. I have:
> 
> -
> package t::MockApp;
> 
> use Mojo::Base -strict;
> 
> use Mojolicious::Lite;
> 
> websocket '/my-websocket-endpoint' => sub { ... }
> -
> 
>   … and I’d like my tested $ua (Mojo::UserAgent->new()) to call logic 
> defined in t::MockApp, rather than going out to the real world. I’d also like 
> to define other mock server classes and have other parts of the test use 
> those classes instead.
> 
>   I’ve tried “$ua->server->app($TEST_MOJO_APP) if $TEST_MOJO_APP” in my 
> tested code, but that doesn’t seem to work. (The client times out rather than 
> connecting to my WS server logic.)

Follow-up: I have this working but only if I alter the tested logic to give a 
relative URL rather than an absolute URL to $tx->websocket().

Is there any tooling in place for handling absolute URLs in such setups? I can 
override $tx->websocket() but wonder if there’s any ready-made sugar for this.

Thank you!

-FG

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/C643F292-7C2E-4E82-B794-9B4446AD4D6E%40felipegasper.com.


Re: [Mojolicious] Deprecating or Transferring Mojo::ACME

2020-02-19 Thread Felipe Gasper
Hi Joel,

I’ve got a proof-of-concept branch of Net::ACME2 that uses 
Net::Curl::Promiser rather than HTTP::Tiny; to use Mojo would likely be a 
pretty similar change. If anyone’s interested in trying it out, let me know.

-FG


> On Feb 19, 2020, at 10:28 PM, Joel Berger  wrote:
> 
> As I've posted on blogs.perl.org, I'll be deprecating or transferring 
> maintainership of Mojo::ACME in the near future. If you're interested in 
> taking it please let me know and I'll consider it. 
> 
> http://blogs.perl.org/users/joel_berger/2020/02/deprecating-or-transferring-mojoacme.html
> 
> Cheers,
> Joel
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/647a4402-e9c3-4fdb-a6cc-dbf545589564%40googlegroups.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/3DE334A6-FD4C-41DF-8304-7D6D4E7B9906%40felipegasper.com.


Re: [Mojolicious] Get an array from checkboxes

2020-03-02 Thread Felipe Gasper
https://developer.mozilla.org/en-US/docs/Web/API/FormData

^^ Also, if you’re not sure whether the problem is in Perl or in the browser, 
you can use this to see what data the browser intends to send prior to sending.

-FG


> On Mar 2, 2020, at 10:51 AM, Dan Book  wrote:
> 
> That is correct, it should return all "values" of checked items with that 
> "name". I don't know what the distinction of "new checked values" is that you 
> mention. Make sure the checkboxes are all within the same form tag.
> 
> -Dan
> 
> On Mon, Mar 2, 2020 at 10:38 AM mab974  wrote:
> Thanks Dan !
> 
> It seems I get only the NEW checked values not all checked values.
> Do I use it the right way ?
> 
>  my @members = @{$c->every_param('groupMembers')};
> 
> 
> 
> Selon Dan Book  :
> > param returns a single value, by design, because this avoids the context
> > sensitivity bug that led to for example
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1572. To get
> > multiple values, use every_param, which returns an array reference:
> > 
> >   my $groups = $c->every_param('groupMemberships');
> > 
> > -Dan
> > 
> > On Sun, Mar 1, 2020 at 3:46 PM mab974  wrote:
> > 
> > > Hi,
> > >
> > > How do I get multiple checkbox values as an array?
> > > I always get the value of the last checked checkbox.
> > >
> > >
> > > my example :
> > > in template
> > >
> > >   %= check_box 'groupMemberships' => $groupname
> > >
> > > or when checked
> > >
> > > 
> > >
> > > and in controller
> > >
> > > my @groups = $c->param('groupMemberships');
> > >
> > > Thanks in advance.
> > >
> > > Regards,
> > >
> > > -*-
> > > mab974
> > >
> > > --
> 
> -*- 
> mab974
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/20200302193802.4f94f42c5414f87a1cf133d8%40gmail.com.
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/CABMkAVWFJ1PAZ%3D7CY9J9MktTB-rNCo8A36p3K2uGppPhHTF7-w%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/3CC64B1E-9F5B-4CE4-9C77-8931AA239081%40felipegasper.com.


[Mojolicious] Async ACME2 (Let’s Encrypt)

2020-03-21 Thread Felipe Gasper
https://github.com/FGasper/p5-Net-ACME2/tree/async

Supports Mojo via Net::Curl::Promiser.

Still experimental; file bugs as you find them. Enjoy!

-FG

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/FDCA2ED2-AF65-4365-8374-78B3EC746808%40felipegasper.com.


Re: [Mojolicious] Re: curl works, Mojo::UserAgent doesn't

2020-05-14 Thread Felipe Gasper
FWIW, you can use libcurl with Mojo via Net::Curl::Promiser::Mojo. That may be 
your easiest solution?

-FG

> On May 14, 2020, at 07:38, 'Michael Lackhoff' via Mojolicious 
>  wrote:
> 
> 
>> Am 14.05.2020 um 05:08 schrieb Stefan Adams:
>> > I'm certain you'll be able to accomplish this with M::UA. Can you share
> Just to reduce complexity I changed everything to plain HTTP, so no SSL,
> keys or certificates.
> 
>> > what the HTML error produced is?
> It is not really a normal error page, just a page from the UI. The most
> relevant lines are these:
> Invalid variable name.
> Wiederholen Sie das Update oder starten Sie die FRITZ!Box neu.
> [German for: repeat the update(sic! I wanted to backup the box, not
> update) or restart your FRITZ!Box]
> 
>> > Can you share the output that you are comparing that you are noticing is so
>> > similar between curl and M::UA? You're using -v for curl. Also set the
>> > MOJO_CLIENT_DEBUG env variable to 1.
> Here is what curl gives (with --trace-ascii):
> => Send header, 200 bytes (0xc8)
> : POST /cgi-bin/firmwarecfg HTTP/1.1
> 0024: Host: fritz.box
> 0035: User-Agent: curl/7.58.0
> 004e: Accept: */*
> 005b: Content-Length: 370
> 0070: Content-Type: multipart/form-data; boundary=
> 00b0: 565a580ebeb0c567
> 00c6:
> => Send data, 370 bytes (0x172)
> : --565a580ebeb0c567
> 002c: Content-Disposition: form-data; name="sid"
> 0058:
> 005a: 4e240384c30c909d
> 006c: --565a580ebeb0c567
> 0098: Content-Disposition: form-data; name="ImportExportPassword"
> 00d5:
> 00d7: backup
> 00df: --565a580ebeb0c567
> 010b: Content-Disposition: form-data; name="ConfigExport"
> 0140:
> 0142:
> 0144: --565a580ebeb0c567--
> <= Recv header, 17 bytes (0x11)
> : HTTP/1.1 200 OK
> 
> 
>> > See how it works comparing curl to:
>> > 
>> >$ env MOJO_CLIENT_DEBUG=1 mojo get -v -M POST -f sid=$SID -f
>> > ImportExportPassword=$BAKPWD -f ConfigExport= http
>> > ://fritz.box/cgi-bin/firmwarecfg 
> The empty ConfigExport parameter gets lost with this command and the
> Content-Type is different:
> 
> -- Blocking request (http://fritz.box/cgi-bin/firmwarecfg)
> -- Connect 7c84d2d7396d9d2ff9571982f73240cb (http://fritz.box:80)
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> POST /cgi-bin/firmwarecfg HTTP/1.1\x0d
> Content-Length: 48\x0d
> User-Agent: Mojolicious (Perl)\x0d
> Accept-Encoding: gzip\x0d
> Content-Type: application/x-www-form-urlencoded\x0d
> Host: fritz.box\x0d
> \x0d
> ImportExportPassword=backup&sid=4e240384c30c909d
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> 
> -- Client <<< Server (http://fritz.box/cgi-bin/firmwarecfg)
> HTTP/1.1 200 OK\x0d
> 
> 
> 
> With DEBUG on and my code (s. my original message and below) I get this:
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> POST /cgi-bin/firmwarecfg HTTP/1.1\x0d
> Accept-Encoding: gzip, deflate\x0d
> Content-Type: multipart/form-data; boundary=tyUPX\x0d
> Accept: */*\x0d
> Host: fritz.box\x0d
> Content-Length: 230\x0d
> User-Agent: Mojolicious (Perl)\x0d
> \x0d
> --tyUPX\x0d
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> Content-Disposition: form-data; name="ConfigExport"\x0d
> \x0d
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> \x0d
> --tyUPX\x0d
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> Content-Disposition: form-data; name="ImportExportPassword"\x0d
> \x0d
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> backup
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> \x0d
> --tyUPX\x0d
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> Content-Disposition: form-data; name="sid"\x0d
> \x0d
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> 33cb272bcd34940b
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> \x0d
> --tyUPX--\x0d
> 
> -- Client >>> Server (http://fritz.box/cgi-bin/firmwarecfg)
> 
> -- Client <<< Server (http://fritz.box/cgi-bin/firmwarecfg)
> HTTP/1.1 200 OK\x0d
> 
> which for me looks very much the same as the curl version but as I said,
> curl gives the backup file whereas M::U just gives the HTML page back,
> indicating that something went wrong.
> I can only spot very minor differences that is why I am running out of
> ideas:
> - the boundary used by M::U is quite short
> - the form parameters are not in the same order
> - Accept-Encoding header (is also sent from Firefox where it works)
> - the different SID is normal (my script always makes a fresch login)
> 
> Looks very strange to me
> -Michael
> 
>> > On Wed, May 13, 2020, 4:56 PM 'Michael Lackhoff' via Mojolicious <
>> > mojolicious@googlegroups.com> wrote:
>> > 
>>> >> I had quite a bit of success recently using Mojo::UserAgent so I tried to
>>> >> replace a curl command to do a backup of my Fritz.box router with M:

Re: [Mojolicious] Re: curl works, Mojo::UserAgent doesn't

2020-05-14 Thread Felipe Gasper
Net::Curl::Promiser wouldn’t keep you from using any of Mojo’s other 
capabilities. It’s just an alternative way of doing asynchronous HTTP requests; 
i.e., it’s a substitute specifically for Mojo::UserAgent. It can also 
facilitate use of FTP, IMAP, etc. by virtue of libcurl’s support for those 
protocols.

I wouldn’t necessarily describe the interface itself as “easy” since it’s 
basically a direct port of libcurl’s own interface. The idea is more that, if 
you know curl is doing what you want, then just use curl rather than M::UA, and 
keep on trucking with all else that Mojo has to offer.

-FG

> On May 14, 2020, at 8:06 AM, 'Michael Lackhoff' via Mojolicious 
>  wrote:
> 
> Well, the easiest solution would be to just use curl.
> But M::U is a powerful tool I find myself using it more and more and I would 
> like to better understand such tools.
> It looks great but if it has some severe shortcomings I want to know before 
> doing lots of mission critical stuff with it.
> 
> But thanks for your suggestion. It is always good to know further options.
> -Michael
> 
> 
> Am Donnerstag, 14. Mai 2020 13:47:41 UTC+2 schrieb Felipe Gasper:
> FWIW, you can use libcurl with Mojo via Net::Curl::Promiser::Mojo. That may 
> be your easiest solution?
> 
> -FG
> 
>> On May 14, 2020, at 07:38, 'Michael Lackhoff' via Mojolicious 
>>  wrote:
>> 
>> 
>> Am 14.05.2020 um 05:08 schrieb Stefan Adams:
>> 
>>> > 
>>> I'm certain you'll be able to accomplish this with M::UA. Can you share
>>> 
>> Just to reduce complexity I changed everything to plain HTTP, so no SSL,
>> keys or certificates.
>> 
>> 
>>> > 
>>> what the HTML error produced is?
>>> 
>> It is not really a normal error page, just a page from the UI. The most
>> relevant lines are these:
>> Invalid variable name.
>> Wiederholen Sie das Update oder starten Sie die FRITZ!Box neu.
>> [German for: repeat the update(sic! I wanted to backup the box, not
>> update) or restart your FRITZ!Box]
>> 
>> 
>>> > 
>>> Can you share the output that you are comparing that you are noticing is so
>>> 
>>> > 
>>> similar between curl and M::UA? You're using -v for curl. Also set the
>>> 
>>> > 
>>> MOJO_CLIENT_DEBUG env variable to 1.
>>> 
>> Here is what curl gives (with --trace-ascii):
>> => Send header, 200 bytes (0xc8)
>> : POST /cgi-bin/firmwarecfg HTTP/1.1
>> 0024: Host: fritz.box
>> 0035: User-Agent: curl/7.58.0
>> 004e: Accept: */*
>> 005b: Content-Length: 370
>> 0070: Content-Type: multipart/form-data; boundary=
>> 00b0: 565a580ebeb0c567
>> 00c6:
>> => Send data, 370 bytes (0x172)
>> : --
>> 565a580ebeb0c567
>> 002c: Content-Disposition: form-data; name="sid"
>> 0058:
>> 005a: 4e240384c30c909d
>> 006c: --
>> 565a580ebeb0c567
>> 0098: Content-Disposition: form-data; name="ImportExportPassword"
>> 00d5:
>> 00d7: backup
>> 00df: --
>> 565a580ebeb0c567
>> 010b: Content-Disposition: form-data; name="ConfigExport"
>> 0140:
>> 0142:
>> 0144: --
>> 565a580ebeb0c567--
>> <= Recv header, 17 bytes (0x11)
>> : HTTP/1.1 200 OK
>> 
>> 
>> 
>>> > 
>>> See how it works comparing curl to:
>>> 
>>> > 
>>> > 
>>>$ env MOJO_CLIENT_DEBUG=1 mojo get -v -M POST -f sid=$SID -f
>>> 
>>> > 
>>> ImportExportPassword=$BAKPWD -f ConfigExport= http
>>> 
>>> > ://fritz.box/cgi-bin/firmwarecfg <http://fritz.box/cgi-bin/firmwarecfg>
>> The empty ConfigExport parameter gets lost with this command and the
>> Content-Type is different:
>> 
>> -- Blocking request (
>> http://fritz.box/cgi-bin/firmwarecfg
>> )
>> -- Connect 7c84d2d7396d9d2ff9571982f73240
>> cb (http://fritz.box:80
>> )
>> -- Client >>> Server (
>> http://fritz.box/cgi-bin/firmwarecfg
>> )
>> POST /cgi-bin/firmwarecfg HTTP/1.1\x0d
>> Content-Length: 48\x0d
>> User-Agent: Mojolicious (Perl)\x0d
>> Accept-Encoding: gzip\x0d
>> Content-Type: application/x-www-form-
>> urlencoded\x0d
>> Host: fritz.box\x0d
>> \x0d
>> ImportExportPassword=backup&
>> sid=4e240384c30c909d
>> -- Client >>> Server (
>> http://fritz.box/cgi-bin/firmwarecfg
>> )
>

Re: [Mojolicious] Best alternative for client / server polling?

2020-05-18 Thread Felipe Gasper


> On May 18, 2020, at 7:45 PM, Miguel Manso  wrote:
> 
> Hi there,
> 
> Ive a Perl client that fetched some data every 3 seconds and post it to an 
> API. Both client and server are written using mojo. Client uses 
> Mojo::UserAgent to post JSON and server is a Mojolicious app being served 
> with hypnotoad.
> 
> I can have dozens of these clients which mean that each of them will be 
> posting data and receiving from the server every 3 secs. I can easily do this 
> using basic post calls but I wonder if there is a better way to achieve the 
> same? Something like keeping connections opened for a period of time while 
> sending and receiving data through the same connection?
> 
> Ive seen websockets info but it seems it’s allways oriented to the client 
> being in JavaScript.
> 
> Any thoughts on the subject?

We’ve had great success deploying WebSocket in lieu of TCP for server-to-server 
communication. You harness the routing that a web framework like Mojo does for 
you--so no futzing with firewalls and the like--but you still get the real-time 
communication that a raw TCP socket would give you. There’s a CLI utility 
called “websocat” that basically functions as “netcat for WebSocket”, if that’s 
of use to you.

An alternative technology, if you only need a server-to-client stream, is 
Server-Sent Events (SSE). It’s basically an open-ended HTTP response, with the 
client parsing each chunk of that response as it arrives. Most browsers support 
it via the EventStream object, and I suspect it’d be pretty straightforward to 
rig up a Mojo SSE client, too. It’s a bit simpler, too, since it follows HTTP 
semantics. Not as robust, though, as it lacks the close status mechanism that 
WebSocket provides. (The server basically has to wait until it sees 
EPIPE/SIGPIPE to know that the client has stopped listening.)

-FG

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/B7BB55F8-9810-440B-9F79-919A1B664D05%40felipegasper.com.


Re: [Mojolicious] Re: web cam websocket

2020-09-14 Thread Felipe Gasper
That seems an odd error from Chrome, if that’s the fix .. was the browser 
sending a subprotocol in the handshake?

-F

> On Sep 14, 2020, at 07:37, Mikhail  wrote:
> 
> Thanks! Forever ♥ Mojolicious!
> 
> понедельник, 14 сентября 2020 г. в 13:41:46 UTC+5, Sebastian Riedel: 
>> Then you need to negotiate a subprotocol.
>> 
>> --
>> 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 mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/68624663-2baf-4bc2-a24e-b8fc135ff15dn%40googlegroups.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/33AC68A2-F3E8-4C8B-BB60-05D6EABA46A1%40felipegasper.com.


Re: [Mojolicious] Re: web cam websocket

2020-09-15 Thread Felipe Gasper
RFC 6455/1.9 states:

The client can request that the server use a specific subprotocol by
   including the |Sec-WebSocket-Protocol| field in its handshake.  If it
   is specified, the server needs to include the same field and one of
   the selected subprotocol values in its response for the connection to
   be established.

Given this, should Mojo even send a response? Or if it does, should it at least 
warn “failed to negotiate subprotocol; sending handshake response anyway”?

-FG

> On Sep 15, 2020, at 04:21, Mikhail  wrote:
> 
> 
> Chrome browser  absolutely described the error in that it sent a subprotocol 
> header ('null' for that case). So solve
> 
> $ws->tx->with_protocols('binary', 'null');
> 
> Let binary subprotocol is present also.
> понедельник, 14 сентября 2020 г. в 17:29:31 UTC+5, fel...@felipegasper.com: 
>> That seems an odd error from Chrome, if that’s the fix .. was the browser 
>> sending a subprotocol in the handshake?
>> 
>> -F
>> 
 On Sep 14, 2020, at 07:37, Mikhail  wrote:
 
>>> Thanks! Forever ♥ Mojolicious!
>> 
>>> 
>>> 
>>> понедельник, 14 сентября 2020 г. в 13:41:46 UTC+5, Sebastian Riedel: 
 Then you need to negotiate a subprotocol.
 
 --
 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 mojolicious...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/mojolicious/68624663-2baf-4bc2-a24e-b8fc135ff15dn%40googlegroups.com.
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/e4166da1-91ce-40e3-810b-2511725ad8b1n%40googlegroups.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/A14CC5C0-FA85-45B6-9334-DDF35FAD175B%40felipegasper.com.


Re: [Mojolicious] Re: web cam websocket

2020-09-15 Thread Felipe Gasper


> On Sep 15, 2020, at 9:30 AM, Sebastian Riedel  wrote:
> 
> Given this, should Mojo even send a response? Or if it does, should it at 
> least warn “failed to negotiate subprotocol; sending handshake response 
> anyway”?
> 
>  So you want Mojolicious to cause a TCP level connection error instead of 
> letting the handshake fail properly? That seems like a really bad idea.

An HTTP-level error response--maybe 426--would probably be most sensible.

-FG

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/BA5FBD04-A338-481B-9D9A-CE5834EE732F%40felipegasper.com.


Re: [Mojolicious] Re: web cam websocket

2020-09-15 Thread Felipe Gasper


> On Sep 15, 2020, at 11:20 AM, Sebastian Riedel  wrote:
> 
> An HTTP-level error response--maybe 426--would probably be most sensible. 
> 
> What error would common browsers give in that case? 

They’d give whatever error as with any other HTTP-level failure during a WS 
handshake.

Chrome shows a console error with the response code. A 404, for example, yields:


Error during WebSocket handshake: Unexpected response code: 404


-FG

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/6AB67496-744B-4CC5-9899-DFE0DEDF6965%40felipegasper.com.


[Mojolicious] Cancel in-flight HTTP request?

2020-10-23 Thread Felipe Gasper
Hi all,

Does Mojo::UA offer a control to cancel an in-flight HTTP request? I 
don’t see one in the docs but wonder if I’m just missing it.

(The promise, of course, can be pre-resolved/rejected, but that doesn’t 
appear to affect the underlying HTTP request.)

Thank you!

cheers,
-Felipe

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/10E98F2C-174C-4459-AC05-C8FA7F623943%40felipegasper.com.


Re: [Mojolicious] Cancel in-flight HTTP request?

2020-10-23 Thread Felipe Gasper
Thank you!

When I try:


use Mojo::UserAgent;

my $ua = Mojo::UserAgent->new;

my $p = $ua->get_p('http://www.google.com');

Mojo::Promise->timer(0.01)->then( sub { print "canceling\n"; $p->completed() } 
);

Mojo::Promise->timer(2)->wait();


… then strace that script, the request continues even after the call to 
completed().

Am I just “holding it wrong”?

cheers,
-FG


> On Oct 23, 2020, at 10:13 AM, Dmitry L.  wrote:
> 
> https://metacpan.org/pod/Mojo::Transaction#completed
> 
> On Fri, 23 Oct 2020 at 17:07, Felipe Gasper  wrote:
>> 
>> Hi all,
>> 
>>Does Mojo::UA offer a control to cancel an in-flight HTTP request? I 
>> don’t see one in the docs but wonder if I’m just missing it.
>> 
>>(The promise, of course, can be pre-resolved/rejected, but that 
>> doesn’t appear to affect the underlying HTTP request.)
>> 
>>Thank you!
>> 
>> cheers,
>> -Felipe
>> 
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/mojolicious/10E98F2C-174C-4459-AC05-C8FA7F623943%40felipegasper.com.
> 
> 
> 
> -- 
> //wbr, Dmitry L.
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/CAKgzkX24PZUkSOQy1%2BBcx%2BhGkbNsXSPULB5fjDx9kZLb2qOY_w%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/2E2D79DF-709B-4793-AD88-95E32D242D2F%40felipegasper.com.


Re: [Mojolicious] Cancel in-flight HTTP request?

2020-10-23 Thread Felipe Gasper


> On Oct 23, 2020, at 10:42 AM, Dmitry L.  wrote:
> 
>> my $p = $ua->get_p('http://www.google.com');
>> 
> https://metacpan.org/pod/Mojo::UserAgent#get_p returns a Mojo::Promise object
> 
>> Mojo::Promise->timer(0.01)->then( sub { print "canceling\n"; $p->completed() 
>> } );
>> 
> https://metacpan.org/pod/Mojo::Promise doesn't have `completed` method
> your are calling
> 
> You have to build Mojo::Transaction via $ua->build_tx and do ->completed on it

Ahh ok. Yeah I realized after my initial response to you that that was what was 
going on there. (And my mojo isn’t new enough to have the nifty new 
unhandled-rejection warning.)

I’ll look into this (and Sebastian’s as well). Thank you!

-FG

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/BA7E932D-50B9-4529-876E-5015EED00078%40felipegasper.com.


Re: [Mojolicious] Cancel in-flight HTTP request?

2020-10-26 Thread Felipe Gasper


> On Oct 23, 2020, at 10:42 AM, Dmitry L.  wrote:
> 
>> my $p = $ua->get_p('http://www.google.com');
>> 
> https://metacpan.org/pod/Mojo::UserAgent#get_p returns a Mojo::Promise object
> 
>> Mojo::Promise->timer(0.01)->then( sub { print "canceling\n"; $p->completed() 
>> } );
>> 
> https://metacpan.org/pod/Mojo::Promise doesn't have `completed` method
> your are calling
> 
> You have to build Mojo::Transaction via $ua->build_tx and do ->completed on it

Follow-up to this … it’s still not canceling.

=
use v5.26;
use Mojo::UserAgent;

$| = 1;

my $ua = Mojo::UserAgent->new();

my $tx = $ua->build_tx( GET => 'http://google.com' );
$tx->on( connection => sub { $tx->completed(); say "canceled" } );

$ua->start_p($tx)->then( sub { say "finished" } );

Mojo::IOLoop->timer(2, sub { Mojo::IOLoop->stop() });

Mojo::IOLoop->start();
=

It prints “canceled”, but strace shows that it continues with the request after 
then. Is there something else I need to do?

Sebastian: Do you recall off-hand which tests set a response error from the 
client logic? I’ve looked over the ones that seem like they might be related, 
but I’ve not found it.

Thank you both!

cheers,
-Felipe

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/598A1F26-9A63-45E1-80A5-7EA543D69EE6%40felipegasper.com.


Re: [Mojolicious] Suggestions how to avoid "Useless use of private variable in void context" ?

2020-11-16 Thread Felipe Gasper
I think you could do:

$tx = $tx;

… instead. (It might be worth updating the FAQ to do that?)

-F

> On Nov 16, 2020, at 8:08 AM, Edward Baudrez  wrote:
> 
> Hello list
> 
> There is this hint in the FAQ about keeping a strong reference to the 
> transaction object $tx around, so that the message "Transaction already 
> destroyed" does not appear in the logs:
> 
> https://docs.mojolicious.org/Mojolicious/Guides/FAQ#What-does-Transaction-already-destroyed-mean
> 
> However, that yields a warning, viz. "Useless use of private variable in void 
> context" at the lone "$tx". Any hints how to avoid this warning?
> 
> 
> Kind regards
> Edward
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/mojolicious/8b3ab4a2-5f18-4d1f-8743-82b573af26bbn%40googlegroups.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/F3AF3253-E058-4351-B913-12244352F95E%40felipegasper.com.


[Mojolicious] multiple concurrent event loops

2021-02-19 Thread Felipe Gasper
Hello,

In a PR thread yesterday Sebastian mentioned that Mojo allows multiple 
concurrent event loops.

When and why would someone want such a configuration?

Thank you!

cheers,
-Felipe Gasper

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/EED46BD6-1A44-4B7C-B5C9-50A4D276D17B%40felipegasper.com.