You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jesús González <je...@vmware.com> on 2023/01/17 18:12:35 UTC
Re: mod_wasm: Contributing Upstream to Apache
Hola!
Did anyone have the chance to take a look to the latest PR?
It would be great to receive any additional feedback with the upstream contribution in mind.
We are making great progress in our end, now focused on porting more PHP apps for mod_wasm, and support for new language runtimes such as Python and Ruby.
Thanks!
Re: mod_wasm: Contributing Upstream to Apache
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Looking over the WASM Roadmap, it appears that they have a plan for
multithreading within a single target language. That would allow you to
fully support every silly GIL-addled language runtime out there, which
would be very compelling.
On Fri, Jan 27, 2023 at 1:33 PM Joe Schaefer <jo...@sunstarsys.com> wrote:
> A native interface outside of CGI compat for apreq would be a killer new
> feature, because it really finishes our vision for apreq as the
> one-HTML-spec-parser for all native apps, regardless of language choice. Of
> course this would be a new opt-in feature for target languages to take
> advantage of, but it will really set apart the speed freaks in your
> userbase.
>
>
Re: mod_wasm: Contributing Upstream to Apache
Posted by Joe Schaefer <jo...@sunstarsys.com>.
A native interface outside of CGI compat for apreq would be a killer new
feature, because it really finishes our vision for apreq as the
one-HTML-spec-parser for all native apps, regardless of language choice. Of
course this would be a new opt-in feature for target languages to take
advantage of, but it will really set apart the speed freaks in your
userbase.
Re: mod_wasm: Contributing Upstream to Apache
Posted by Frank Gingras <th...@apache.org>.
As per the instructions:
To unsubscribe, send a messages to *users-unsubscribe@httpd.apache.org
<us...@httpd.apache.org>* (or, if you are subscribed to the
digest version of the list, send to *users-digest-unsubscribe@httpd.apache.org
<us...@httpd.apache.org>* ). You must send the
unsubscribe message from the same email address that you used to subscribe
to the list.
To complete the unsubscription process you must reply to a confirmation
email. If you do not receive this confirmation email, please check your
spam filters to see if they are capturing the message.
In this case, you would want to email dev-unsubscribe@httpd.apache.org
On Thu, Jun 1, 2023 at 4:32 PM Dan Ehrlich via dev <de...@httpd.apache.org>
wrote:
> Hi:
>
> Can I be unsubscribed from this list?
>
> Have sent previous messages following all the instructions on this page
> but to no avail:
> https://httpd.apache.org/userslist.html.
>
>
> Best,
>
> Dan
>
> On Fri, Jan 27, 2023 at 11:36 AM Jesús González <je...@vmware.com>
> wrote:
>
>> Thanks Joe. You are correct, this initial implementation is the simplest
>> one to get it off the ground. We plan to continue development and add the
>> streaming functionality, which we know we will need for things like large
>> PDF file generation or support for Proxy-Wasm.
>>
>>
>>
>> Yes, isolating language runtimes (PHP, Python, ...) per thread is a cool
>> feature that enables new possibilities like simultaneously supporting
>> multiple versions of PHP as well as better multi-tenancy (you will be able
>> to keep user's code and assets separate from each other using Wasm built-in
>> isolation mechanism).
>>
>>
>>
>> Regarding apreq, right now we have not had a need to use it as we pass
>> most of the headers and body to the runtimes themselves as the language
>> runtimes code for handling requests, etc. takes care of it as part of the
>> CGI implementation, etc. As we look to add different functionality (i.e.
>> extending Apache itself) we will probably provide access to it from Wasm.
>>
>>
>>
>>
>>
>> *De: *Joe Schaefer <jo...@sunstarsys.com>
>> *Responder a: *"dev@httpd.apache.org" <de...@httpd.apache.org>
>> *Fecha: *jueves, 26 de enero de 2023, 5:17
>> *Para: *"dev@httpd.apache.org" <de...@httpd.apache.org>
>> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>>
>>
>>
>> Still, the idea is wicked cool if mod_wasm really can isolate the Python,
>> PHP, etc targets onto individual POSIX threads.
>>
>>
>>
>> Very exciting stuff for HTTP/2 Webapps.
>>
>
Re: mod_wasm: Contributing Upstream to Apache
Posted by Dan Ehrlich via dev <de...@httpd.apache.org>.
Hi:
Can I be unsubscribed from this list?
Have sent previous messages following all the instructions on this page but
to no avail:
https://httpd.apache.org/userslist.html.
Best,
Dan
On Fri, Jan 27, 2023 at 11:36 AM Jesús González <je...@vmware.com> wrote:
> Thanks Joe. You are correct, this initial implementation is the simplest
> one to get it off the ground. We plan to continue development and add the
> streaming functionality, which we know we will need for things like large
> PDF file generation or support for Proxy-Wasm.
>
>
>
> Yes, isolating language runtimes (PHP, Python, ...) per thread is a cool
> feature that enables new possibilities like simultaneously supporting
> multiple versions of PHP as well as better multi-tenancy (you will be able
> to keep user's code and assets separate from each other using Wasm built-in
> isolation mechanism).
>
>
>
> Regarding apreq, right now we have not had a need to use it as we pass
> most of the headers and body to the runtimes themselves as the language
> runtimes code for handling requests, etc. takes care of it as part of the
> CGI implementation, etc. As we look to add different functionality (i.e.
> extending Apache itself) we will probably provide access to it from Wasm.
>
>
>
>
>
> *De: *Joe Schaefer <jo...@sunstarsys.com>
> *Responder a: *"dev@httpd.apache.org" <de...@httpd.apache.org>
> *Fecha: *jueves, 26 de enero de 2023, 5:17
> *Para: *"dev@httpd.apache.org" <de...@httpd.apache.org>
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
>
>
> Still, the idea is wicked cool if mod_wasm really can isolate the Python,
> PHP, etc targets onto individual POSIX threads.
>
>
>
> Very exciting stuff for HTTP/2 Webapps.
>
Re: mod_wasm: Contributing Upstream to Apache
Posted by Jesús González <je...@vmware.com>.
Thanks Joe. You are correct, this initial implementation is the simplest one to get it off the ground. We plan to continue development and add the streaming functionality, which we know we will need for things like large PDF file generation or support for Proxy-Wasm.
Yes, isolating language runtimes (PHP, Python, ...) per thread is a cool feature that enables new possibilities like simultaneously supporting multiple versions of PHP as well as better multi-tenancy (you will be able to keep user's code and assets separate from each other using Wasm built-in isolation mechanism).
Regarding apreq, right now we have not had a need to use it as we pass most of the headers and body to the runtimes themselves as the language runtimes code for handling requests, etc. takes care of it as part of the CGI implementation, etc. As we look to add different functionality (i.e. extending Apache itself) we will probably provide access to it from Wasm.
De: Joe Schaefer <jo...@sunstarsys.com>
Responder a: "dev@httpd.apache.org" <de...@httpd.apache.org>
Fecha: jueves, 26 de enero de 2023, 5:17
Para: "dev@httpd.apache.org" <de...@httpd.apache.org>
Asunto: Re: mod_wasm: Contributing Upstream to Apache
Still, the idea is wicked cool if mod_wasm really can isolate the Python, PHP, etc targets onto individual POSIX threads.
Very exciting stuff for HTTP/2 Webapps.
Re: mod_wasm: Contributing Upstream to Apache
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Still, the idea is wicked cool if mod_wasm really can isolate the Python,
PHP, etc targets onto individual POSIX threads.
Very exciting stuff for HTTP/2 Webapps.
On Wed, Jan 25, 2023 at 4:31 AM Joe Schaefer <jo...@sunstarsys.com> wrote:
> Looked at the PR- the IO is pretty primitive (no streaming anywhere).
> Probably not fatal for Webapps, but it could use some better relations with
> the filter stack and bucket brigades.
>
> Joe Schaefer, Ph.D
> <jo...@sunstarsys.com>
> +1 (954) 253-3732
> SunStar Systems, Inc.
> *Orion - The Enterprise Jamstack Wiki*
>
> ------------------------------
> *From:* Joe Schaefer <jo...@sunstarsys.com>
> *Sent:* Tuesday, January 24, 2023 4:06:13 PM
> *To:* dev@httpd.apache.org <de...@httpd.apache.org>
> *Subject:* Re: mod_wasm: Contributing Upstream to Apache
>
> Would be great to marry it to apreq, too.
>
> On Tue, Jan 24, 2023 at 4:04 PM Joe Schaefer <jo...@sunstarsys.com> wrote:
>
> It is impossible to run mod_h2 without it or similar.
>
> On Tue, Jan 24, 2023 at 3:37 PM Eric Covener <co...@gmail.com> wrote:
>
> > We are still very interested in contributing this module upstream and
> helping to maintain it. Please, let us know what improvements or changes
> would be needed for it to be considered ready for inclusion.
>
> As a pessimistic PMC member not caring about WASM or these languages,
> I worry that marrying the lifecycle together is not advantageous for
> either side. Of course I worry about being stuck with the pieces when
> employer interest wanes or after turnover. It does not seem like it's
> strictly necessary to be part of the server distribution (there are
> many examples of successful out-of-tree modules).
>
> However the above is no veto.
>
> --
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>
<jo...@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: mod_wasm: Contributing Upstream to Apache
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Looked at the PR- the IO is pretty primitive (no streaming anywhere). Probably not fatal for Webapps, but it could use some better relations with the filter stack and bucket brigades.
Joe Schaefer, Ph.D
<jo...@sunstarsys.com>
+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki
________________________________
From: Joe Schaefer <jo...@sunstarsys.com>
Sent: Tuesday, January 24, 2023 4:06:13 PM
To: dev@httpd.apache.org <de...@httpd.apache.org>
Subject: Re: mod_wasm: Contributing Upstream to Apache
Would be great to marry it to apreq, too.
On Tue, Jan 24, 2023 at 4:04 PM Joe Schaefer <jo...@sunstarsys.com>> wrote:
It is impossible to run mod_h2 without it or similar.
On Tue, Jan 24, 2023 at 3:37 PM Eric Covener <co...@gmail.com>> wrote:
> We are still very interested in contributing this module upstream and helping to maintain it. Please, let us know what improvements or changes would be needed for it to be considered ready for inclusion.
As a pessimistic PMC member not caring about WASM or these languages,
I worry that marrying the lifecycle together is not advantageous for
either side. Of course I worry about being stuck with the pieces when
employer interest wanes or after turnover. It does not seem like it's
strictly necessary to be part of the server distribution (there are
many examples of successful out-of-tree modules).
However the above is no veto.
Re: mod_wasm: Contributing Upstream to Apache
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Would be great to marry it to apreq, too.
On Tue, Jan 24, 2023 at 4:04 PM Joe Schaefer <jo...@sunstarsys.com> wrote:
> It is impossible to run mod_h2 without it or similar.
>
> On Tue, Jan 24, 2023 at 3:37 PM Eric Covener <co...@gmail.com> wrote:
>
>> > We are still very interested in contributing this module upstream and
>> helping to maintain it. Please, let us know what improvements or changes
>> would be needed for it to be considered ready for inclusion.
>>
>> As a pessimistic PMC member not caring about WASM or these languages,
>> I worry that marrying the lifecycle together is not advantageous for
>> either side. Of course I worry about being stuck with the pieces when
>> employer interest wanes or after turnover. It does not seem like it's
>> strictly necessary to be part of the server distribution (there are
>> many examples of successful out-of-tree modules).
>>
>> However the above is no veto.
>>
>
Re: mod_wasm: Contributing Upstream to Apache
Posted by Joe Schaefer <jo...@sunstarsys.com>.
It is impossible to run mod_h2 without it or similar.
On Tue, Jan 24, 2023 at 3:37 PM Eric Covener <co...@gmail.com> wrote:
> > We are still very interested in contributing this module upstream and
> helping to maintain it. Please, let us know what improvements or changes
> would be needed for it to be considered ready for inclusion.
>
> As a pessimistic PMC member not caring about WASM or these languages,
> I worry that marrying the lifecycle together is not advantageous for
> either side. Of course I worry about being stuck with the pieces when
> employer interest wanes or after turnover. It does not seem like it's
> strictly necessary to be part of the server distribution (there are
> many examples of successful out-of-tree modules).
>
> However the above is no veto.
>
Re: mod_wasm: Contributing Upstream to Apache
Posted by Eric Covener <co...@gmail.com>.
> We are still very interested in contributing this module upstream and helping to maintain it. Please, let us know what improvements or changes would be needed for it to be considered ready for inclusion.
As a pessimistic PMC member not caring about WASM or these languages,
I worry that marrying the lifecycle together is not advantageous for
either side. Of course I worry about being stuck with the pieces when
employer interest wanes or after turnover. It does not seem like it's
strictly necessary to be part of the server distribution (there are
many examples of successful out-of-tree modules).
However the above is no veto.
Re: mod_wasm: Contributing Upstream to Apache
Posted by Jesús González <je...@vmware.com>.
Hola!
I wanted to update you on our progress since we have recently published new WebAssembly builds for several language runtimes, including:
- PHP 8.1.11 and 8.2.0
- Python 3.11.1
- Ruby 3.2.0
With the inclusion of multi-module support in the mod_wasm v0.10.0 release, Apache can now serve different applications written in these languages using just mod_wasm, all under the WebAssembly security model.
We also opened a pull request (PR#335) about a month ago that includes the source code, documentation, and scripting needed to build mod_wasm as an experimental module, as well as a test to build it on Travis CI.
We are still very interested in contributing this module upstream and helping to maintain it. Please, let us know what improvements or changes would be needed for it to be considered ready for inclusion.
Thanks!