Mailing List Archive

On 1/28/2019 1:53 PM, Mark Blackman wrote:
>
> https://perldoc.perl.org/threads.html#WARNING? Threads are discouraged
> in Perl these days

Yes, that is indeed what the documentation says; however, there is a far
cry between "Perl is single-threaded by design and history and has no
reliable support for threading" and "use of threads is discouraged in perl".

Looking back to the original discussion that led to that caveat
https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html
a good summary of why it is there is:

"The patch came about because unmanaged expectations of support are
causing social problems"

And further discussion about it
https://www.perlmonks.org/?node_id=1107534 has a similar insight:

"that this particular formulation is just smoke and mirrors to repel
'annoying newbies"

Then in this bug discussing the verbiage
https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer comments:

"The fact is that threads work, they are maintained, and they currently
do not have any bugs preventing their use."

Basically, perl threads are heavyweight, not lightweight, and use of
non-thread safe Perl code whether your own or in third-party modules
will cause potentially nondeterministic problems. The warning is
basically there to scare away people who don't have sufficient expertise
to make it work and will likely come complain and ask for help with
something the developers don't want to have to explain over and over again.

Back when I was running DCE/DFS and maintaining the perl modules on top
of that, I used threaded perl heavily with no issues. As long as the
mechanism of and caveats regarding Perl threads are understood, and
there is a justifiable reason to be using them rather than some other
construct, discouraged is not deprecated nor unavailable/unreliable.

> On 28 Jan 2019, at 23:00, Paul B. Henson <henson@acm.org> wrote:
>
> On 1/28/2019 1:53 PM, Mark Blackman wrote:
>> https://perldoc.perl.org/threads.html#WARNING Threads are discouraged in Perl these days
>
> Yes, that is indeed what the documentation says; however, there is a far cry between "Perl is single-threaded by design and history and has no reliable support for threading" and "use of threads is discouraged in perl".
>
> Looking back to the original discussion that led to that caveat https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html a good summary of why it is there is:
>
> "The patch came about because unmanaged expectations of support are causing social problems"
>
> And further discussion about it https://www.perlmonks.org/?node_id=1107534 has a similar insight:
>
> "that this particular formulation is just smoke and mirrors to repel 'annoying newbies"
>
> Then in this bug discussing the verbiage https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer comments:
>
> "The fact is that threads work, they are maintained, and they currently do not have any bugs preventing their use."
>
> Basically, perl threads are heavyweight, not lightweight, and use of non-thread safe Perl code whether your own or in third-party modules will cause potentially nondeterministic problems. The warning is basically there to scare away people who don't have sufficient expertise to make it work and will likely come complain and ask for help with something the developers don't want to have to explain over and over again.
>
> Back when I was running DCE/DFS and maintaining the perl modules on top of that, I used threaded perl heavily with no issues. As long as the mechanism of and caveats regarding Perl threads are understood, and there is a justifiable reason to be using them rather than some other construct, discouraged is not deprecated nor unavailable/unreliable.

"Threads are implemented in a way that make them easy to misuse." == "single threaded by design” in my book, but your mileage may vary. I believe threads were retrofitted to Perl and I see very little use of threads in the wild myself. Relying on threads in Perl with real-world third-party XS modules that aren’t thread-safe is equivalent to unreliable. Base Perl might be safe enough, but nobody runs real-world apps with pure Perl alone IME.

I am glad you made threads work well in production, but I suspect you’re in a minority.

- Mark

We also use threads without any problem in production. Main use is sharing
caches so that multiple mod_perl interpreters don'teach store the same
cached information. Following a few simple and documented rules, we've had
no issues with using threads.

On Mon, Jan 28, 2019 at 6:18 PM Mark Blackman <mark@blackmans.org> wrote:

>
>
> > On 28 Jan 2019, at 23:00, Paul B. Henson <henson@acm.org> wrote:
> >
> > On 1/28/2019 1:53 PM, Mark Blackman wrote:
> >> https://perldoc.perl.org/threads.html#WARNING Threads are discouraged
> in Perl these days
> >
> > Yes, that is indeed what the documentation says; however, there is a far
> cry between "Perl is single-threaded by design and history and has no
> reliable support for threading" and "use of threads is discouraged in perl".
> >
> > Looking back to the original discussion that led to that caveat
> https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html
> a good summary of why it is there is:
> >
> > "The patch came about because unmanaged expectations of support are
> causing social problems"
> >
> > And further discussion about it
> https://www.perlmonks.org/?node_id=1107534 has a similar insight:
> >
> > "that this particular formulation is just smoke and mirrors to repel
> 'annoying newbies"
> >
> > Then in this bug discussing the verbiage
> https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer
> comments:
> >
> > "The fact is that threads work, they are maintained, and they currently
> do not have any bugs preventing their use."
> >
> > Basically, perl threads are heavyweight, not lightweight, and use of
> non-thread safe Perl code whether your own or in third-party modules will
> cause potentially nondeterministic problems. The warning is basically there
> to scare away people who don't have sufficient expertise to make it work
> and will likely come complain and ask for help with something the
> developers don't want to have to explain over and over again.
> >
> > Back when I was running DCE/DFS and maintaining the perl modules on top
> of that, I used threaded perl heavily with no issues. As long as the
> mechanism of and caveats regarding Perl threads are understood, and there
> is a justifiable reason to be using them rather than some other construct,
> discouraged is not deprecated nor unavailable/unreliable.
>
> "Threads are implemented in a way that make them easy to misuse." ==
> "single threaded by design” in my book, but your mileage may vary. I
> believe threads were retrofitted to Perl and I see very little use of
> threads in the wild myself. Relying on threads in Perl with real-world
> third-party XS modules that aren’t thread-safe is equivalent to unreliable.
> Base Perl might be safe enough, but nobody runs real-world apps with pure
> Perl alone IME.
>
> I am glad you made threads work well in production, but I suspect you’re
> in a minority.
>
> - Mark
>
>
>
>

We've used Cache::FastMmap at my work to share data between mod_perl
processes. We did not consider using threads because they're not
lightweight.
What the rules you guys are following when it comes to using threads?

On Tue, Jan 29, 2019 at 9:48 AM John Deighan <john.deighan@gmail.com> wrote:

> We also use threads without any problem in production. Main use is sharing
> caches so that multiple mod_perl interpreters don'teach store the same
> cached information. Following a few simple and documented rules, we've had
> no issues with using threads.
>
> On Mon, Jan 28, 2019 at 6:18 PM Mark Blackman <mark@blackmans.org> wrote:
>
>>
>>
>> > On 28 Jan 2019, at 23:00, Paul B. Henson <henson@acm.org> wrote:
>> >
>> > On 1/28/2019 1:53 PM, Mark Blackman wrote:
>> >> https://perldoc.perl.org/threads.html#WARNING Threads are
>> discouraged in Perl these days
>> >
>> > Yes, that is indeed what the documentation says; however, there is a
>> far cry between "Perl is single-threaded by design and history and has no
>> reliable support for threading" and "use of threads is discouraged in perl".
>> >
>> > Looking back to the original discussion that led to that caveat
>> https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html
>> a good summary of why it is there is:
>> >
>> > "The patch came about because unmanaged expectations of support are
>> causing social problems"
>> >
>> > And further discussion about it
>> https://www.perlmonks.org/?node_id=1107534 has a similar insight:
>> >
>> > "that this particular formulation is just smoke and mirrors to repel
>> 'annoying newbies"
>> >
>> > Then in this bug discussing the verbiage
>> https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer
>> comments:
>> >
>> > "The fact is that threads work, they are maintained, and they currently
>> do not have any bugs preventing their use."
>> >
>> > Basically, perl threads are heavyweight, not lightweight, and use of
>> non-thread safe Perl code whether your own or in third-party modules will
>> cause potentially nondeterministic problems. The warning is basically there
>> to scare away people who don't have sufficient expertise to make it work
>> and will likely come complain and ask for help with something the
>> developers don't want to have to explain over and over again.
>> >
>> > Back when I was running DCE/DFS and maintaining the perl modules on top
>> of that, I used threaded perl heavily with no issues. As long as the
>> mechanism of and caveats regarding Perl threads are understood, and there
>> is a justifiable reason to be using them rather than some other construct,
>> discouraged is not deprecated nor unavailable/unreliable.
>>
>> "Threads are implemented in a way that make them easy to misuse." ==
>> "single threaded by design” in my book, but your mileage may vary. I
>> believe threads were retrofitted to Perl and I see very little use of
>> threads in the wild myself. Relying on threads in Perl with real-world
>> third-party XS modules that aren’t thread-safe is equivalent to unreliable.
>> Base Perl might be safe enough, but nobody runs real-world apps with pure
>> Perl alone IME.
>>
>> I am glad you made threads work well in production, but I suspect you’re
>> in a minority.
>>
>> - Mark
>>
>>
>>
>>

We use Redis to share information between mod_perl processes(including our
HTTP sessions). This has the added advantage of allowing all servers in a
cluster to share the same session/cache.

On Tue, Jan 29, 2019 at 7:38 PM Narbey Derbekyan <narbey@gmail.com> wrote:

> We've used Cache::FastMmap at my work to share data between mod_perl
> processes. We did not consider using threads because they're not
> lightweight.
> What the rules you guys are following when it comes to using threads?
>
> On Tue, Jan 29, 2019 at 9:48 AM John Deighan <john.deighan@gmail.com>
> wrote:
>
>> We also use threads without any problem in production. Main use is
>> sharing caches so that multiple mod_perl interpreters don'teach store the
>> same cached information. Following a few simple and documented rules, we've
>> had no issues with using threads.
>>
>> On Mon, Jan 28, 2019 at 6:18 PM Mark Blackman <mark@blackmans.org> wrote:
>>
>>>
>>>
>>> > On 28 Jan 2019, at 23:00, Paul B. Henson <henson@acm.org> wrote:
>>> >
>>> > On 1/28/2019 1:53 PM, Mark Blackman wrote:
>>> >> https://perldoc.perl.org/threads.html#WARNING Threads are
>>> discouraged in Perl these days
>>> >
>>> > Yes, that is indeed what the documentation says; however, there is a
>>> far cry between "Perl is single-threaded by design and history and has no
>>> reliable support for threading" and "use of threads is discouraged in perl".
>>> >
>>> > Looking back to the original discussion that led to that caveat
>>> https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html
>>> a good summary of why it is there is:
>>> >
>>> > "The patch came about because unmanaged expectations of support are
>>> causing social problems"
>>> >
>>> > And further discussion about it
>>> https://www.perlmonks.org/?node_id=1107534 has a similar insight:
>>> >
>>> > "that this particular formulation is just smoke and mirrors to repel
>>> 'annoying newbies"
>>> >
>>> > Then in this bug discussing the verbiage
>>> https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer
>>> comments:
>>> >
>>> > "The fact is that threads work, they are maintained, and they
>>> currently do not have any bugs preventing their use."
>>> >
>>> > Basically, perl threads are heavyweight, not lightweight, and use of
>>> non-thread safe Perl code whether your own or in third-party modules will
>>> cause potentially nondeterministic problems. The warning is basically there
>>> to scare away people who don't have sufficient expertise to make it work
>>> and will likely come complain and ask for help with something the
>>> developers don't want to have to explain over and over again.
>>> >
>>> > Back when I was running DCE/DFS and maintaining the perl modules on
>>> top of that, I used threaded perl heavily with no issues. As long as the
>>> mechanism of and caveats regarding Perl threads are understood, and there
>>> is a justifiable reason to be using them rather than some other construct,
>>> discouraged is not deprecated nor unavailable/unreliable.
>>>
>>> "Threads are implemented in a way that make them easy to misuse." ==
>>> "single threaded by design” in my book, but your mileage may vary. I
>>> believe threads were retrofitted to Perl and I see very little use of
>>> threads in the wild myself. Relying on threads in Perl with real-world
>>> third-party XS modules that aren’t thread-safe is equivalent to unreliable.
>>> Base Perl might be safe enough, but nobody runs real-world apps with pure
>>> Perl alone IME.
>>>
>>> I am glad you made threads work well in production, but I suspect you’re
>>> in a minority.
>>>
>>> - Mark
>>>
>>>
>>>
>>>

--
John Dunlap
*CTO | Lariat *

*Direct:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

The issue, at least for us, has very little to do with static files as we
are already serving them from a CDN(AWS Cloudfront). We have a very large
ember.js application which, on our more complicated screens, can hit the
server 5+ times fetching data just to render the page(all 5+ requests are
initiated simultaneously). We follow a SOFEA(Service Oriented Front End
Architecture) design pattern so we try to build a web service API in
mod_perl and then call it from ember-data. We can then tell our customers
that anything they can do through our UI can also be done through our API.
This helps us kill 2 birds with 1 stone. However, this also means that we
can't create web service endpoints which have a 1:1 correspondence with our
UI and we often have to hit the server 5-6 times to render the page(once
for each drop down box, once per data grid, etc). In this use case, the
concurrency limitations of mod_perl and http/1.1 have become an issue for
us. We've tried throwing bigger servers and memory caches at the problem
but that isn't always enough at peak hours. It's rare that a week goes by
that someone doesn't report slowness at one point or another. Our best
remaining options are to decrease the number of customers(our application
uses a sharded tenancy model) on each server or attempt to scale
horizontally(which would require some rework to stop storing files on the
web server) and both options increase our hosting costs. We've had
extensive discussions about this problem internally and, In the absence of
a better MPM and http/2 support, our best option appears to be putting a
more performant web server in front of Apache, proxying dynamic requests to
Apache, and re-writing our more commonly used endpoints in a language with
a better concurrency model. However, taking that step would effectively
begin our migration away from perl. I know mod_perl has a lot of features
that aren't available in other languages but none of them are an absolute
necessity in our use case and I will be unable to justify staying on
mod_perl if it means ceding fundamental technical advantages to our
competitors. I was hopeful that sponsoring some development could improve
mod_perl's concurrency model but if mod_perl and http/2 are "fundamentally
incompatible", as Mark said, then perhaps we have outgrown mod_perl.

On Wed, Feb 6, 2019 at 9:30 AM Pavel Merdin <pvl1-removthis@merdin.com>
wrote:

> Hi.
> Sorry I'm late in taking a part in the conversation.
>
> I agree with Mark on many points.
> Just wanted to add that if static content is served via a CDN (which it
> should ideally) then maybe there is not much point rushing to support
> HTTP/2 purely for dynamic content. I'm sure HTTP/1.1 will stay for a while
> anyway.
> If static content is served by the same server then it perfectly makes
> sense to add something like nginx to the frontend to serve static content.
> It can also even cache some slow changing dynamic content if needed (making
> user experience better).
> Even with custom authentication handlers nginx supports internal
> redirects, so it's possible to free up perl a process and still serve
> static files via nginx no matter how slow the clients are to get it.
>
> On Mon, 28 Jan 2019 at 20:38, Mark Blackman <mark@blackmans.org> wrote:
>
>>
>>
>> On 27 Jan 2019, at 20:13, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
>>
>> On Fri, Jan 25, 2019 at 11:35 AM John Dunlap <John@lariat.co> wrote:
>>
>>> I'm in the process of optimizing our web application for performance and
>>> one thing that I was really excited to try was mod_http2 because it allows
>>> the browser to send multiple requests through the same TCP connection with
>>> compressed headers. However, when I enabled it and restarted apache I was
>>> greeted with this:
>>>
>>> [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The
>>> mpm module (prefork.c) is not supported by mod_http2. The mpm determines
>>> how things are processed in your server. HTTP/2 has more demands in this
>>> regard and the currently selected mpm will just not do. This is an advisory
>>> warning. Your server will continue to work, but the HTTP/2 protocol will be
>>> inactive.
>>>
>>
>> To this question, the answer should be blatantly obvious; http2 doesn't
>> simply support multiple requests (connection: keepalive solved that)
>> but supports parallel requests. This clearly isn't compatible with any
>> single-threaded/single-worker per connection strategy.
>>
>> A hybrid mod_prefork could be coded to dispatch all worker requests
>> across to distinct worker processes for a single connection, but I
>> don't anticipate anyone interested in doing such development.
>>
>>
>>> The last time I tried to use either mpm_worker or mpm_event my
>>> application was plagued by seemingly random segfaults. Are there any plans
>>> to support other MPM's? If not, the benefits of HTTP2 appear to be
>>> permanently out of reach for our mod_perl applications and that, honestly,
>>> might force us into seriously reevaluating our technology stack. :(
>>>
>>
>> Your compatibility with the worker MPM is likely much stronger than
>> with the event MPM; however... all request workers can behave in a
>> "free threaded" manner under mod_http2, eliminating the relative
>> simplicity of the worker MPM. Working out each and any of these
>> specific segfaults occurs is the only way to improve the situation.
>>
>> For the general mod_perl activity to increase, the Apache Perl Project
>> needs active volunteers and contributions. Consider this entire thread
>> an open invitation to participate.
>>
>>
>> Given that Perl is single-threaded by design and history and has no
>> reliable support for threading, I think that mod_perl and direct http/2
>> support in the same instance are probably fundamentally incompatible. I.e.
>> if you have 10 perl threads running (each in a single process), then it
>> doesn’t matter if you can multiplex 20 http/2 connections, they will all
>> just block. If you’re very attached to mod_perl, you should already be
>> using a 2-tier strategy anyway, with N fat mod_perl Apache instances
>> handling only HTTP/1.1 requests and a second front-end proxy layer of
>> whatever front-end proxy makes sense handling HTTP/2 requests for both
>> static and dynamic content requests. This was standard advice 20 years ago
>> as far as I recall and is even more prudent now.
>>
>> - Mark
>>
>

--
John Dunlap
*CTO | Lariat *

*Direct:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

In message <CAC5eUSvhg5dntxE3VawwSROOrY2K4v4mfxALC9yq1JOYVTOFxg@mail.gmail.com>
, John Dunlap writes:
>extensive discussions about this problem internally and, In the absence of
>a better MPM and http/2 support, our best option appears to be putting a
>more performant web server in front of Apache, proxying dynamic requests to

Please us know using a lighter weight http/2 reverse proxy impacts
your performance.

John
groenveld@acm.org

I can tell you that at least some of the PMC members are on this list.
But I can also tell you that there is essentially no development going
on right now. The PMC is essentially idle, and there aren't any plans to
do anything with regards to improving support for newer MPM's. That
said, the project is open source, and if there are people or companies
out there with the skills and desire to work on those features, things
can get merged, and people can get added to the PMC, or as project
commiters to enable that.

Adam


On 1/28/19 1:30 PM, Russell Lundberg wrote:
> As a long-time fan and user of mod_perl, I like so much the way this
> conversation is turning.
>
> I also wonder if there is a formal process, perhaps an ASF process,
> for coordinating the objectives voiced in this thread with the
> resources required to achieve them?
>
> For example, I believe Steve Hay has led mod_perl2 development lately,
> versions 2.0.9 and 2.0.10, anyway. Should he be engaged, or if the
> leadership of the project has been handed off, whoever has taken
> over?  Do the project steward(s) follow this mailing list?
>
> I don't mean to get in the way of positive and well-intended progress.
> I love mod_perl and only want the best for its future development.
>
> But there might be other development plans in progress with which
> coordination would be helpful.
>
> --
> Read my Latest Blog Post for Telecom Pros: _Excel Telecom Tricks -
> Sequential Numbering
> <https://bangkokbeachtelecom.com/sequential-numbering/>_
> Russell Lundberg
> Bangkok, Thailand +66 91 546 4539
> https://bangkokbeachtelecom.com/
> LinkedIn Profile <https://th.linkedin.com/in/russelllundberg>
>
>
> On Mon, Jan 28, 2019 at 8:04 AM John Dunlap <John@lariat.co
> <mailto:John@lariat.co>> wrote:
>
> I will second what Sive is saying. My organization does not have
> in-house experience writing C code(our internal skill sets are web
> application and database development) but we are potentially
> interested in sponsoring some development on mod_perl with the
> goal of adding support for mpm_worker and or mpm_event because we
> are interested in taking advantage of mod_http2. In addition to
> our sponsorship, we could also assist in testing changes and
> provided segfaults and debugging/environmental information from
> out development and testing environments. Is anyone who is able to
> do this kind of development interested in having a conversation
> with Sive and myself with respect to sponsoring some development?
>
> On Mon, Jan 28, 2019 at 1:11 AM Sive Lindmark <sive@capestream.se
> <mailto:sive@capestream.se>> wrote:
>
> Hi William!
>
> Count on us, my firm can sponsor work as I stated before, and
> also contribute setting up test cases and perhaps also do some
> coding if we have the knowledge to do whats needed.
> My coders are not used to be part of any open source project,
> so we can not take any leading roll though.
>
> How could a sponsor model work?
>
> I have followed crypto world for some time now, and they
> sometimes set up price for someone thats achieve a goal.
> Something we can do here?
>
> /Sive
>
>
>
> --
> John Dunlap
> /CTO | Lariat/
> /
> /
> /*Direct:*/
> /john@lariat.co <mailto:john@lariat.co>/
> /
> *Customer Service:*/
> 877.268.6667
> support@lariat.co <mailto:support@lariat.co>
>

I would like to add my voice to (at least) Russel's and Sive's.
Our situation (and I understand most of the non-Perl-PMC's interventors' in this thread is
similar) is :
- we are interested in the future development of mod_perl, and are willing to "support" or
"sponsor" such development
- we understand that nobody is actively working on mod_perl currently. What we do not
know/understand clearly is "why not ?", and how to possibly change this situation
- we all have some programming resources available, but none of which have the current
competences that we feel are necessary to undertake such development efficiently in the
short term. That is because our organisations are mostly *users* of mod_perl, in the
course of our main activity, which is to develop end-user-oriented application software,
of which a part is currently based on Apache and mod_perl.
- we know that there are people in the mod_perl PMC which do have such competences. We do
not know about their practical availability/willingness to do so.
- we have no hands-on experience of such kinds of open-source, "free" development
projects, and we do not really know "what makes them tick"
- we all have some form of possible contribution in mind and among our possibilities, but
so far, short apparently of providing ourselves some qualified programming staff to do the
work (as Adam mentions below, and William did before him), it does not seem that there is
any obvious avenue open to do so.

To wrap this up somewhat naively and roughly : if we just wanted to pour some money in
such a project, to revive the interest of the current group of people which do have the
competences and experience to work on this efficiently, how would we go about it ?
Or is this not possible/practical/sufficient ?
Could someone of the mod_perl PMC (or the Apache Foundation) take the lead about something
like this, and somehow ask the right questions, and put together a proposal that could
lead to such a "revival" of the Apache/mod_perl project ?
I believe that we could all collectively start by making a financial contribution to such
a preliminary effort, if that is also what it takes to get it going.



On 07.02.2019 03:39, Adam Prime wrote:
> I can tell you that at least some of the PMC members are on this list. But I can
> also tell you that there is essentially no development going on right now. The
> PMC is essentially idle, and there aren't any plans to do anything with regards
> to improving support for newer MPM's. That said, the project is open source, and
> if there are people or companies out there with the skills and desire to work on
> those features, things can get merged, and people can get added to the PMC, or
> as project commiters to enable that.
>
> Adam
>
>
> On 1/28/19 1:30 PM, Russell Lundberg wrote:
>> As a long-time fan and user of mod_perl, I like so much the way this
>> conversation is turning.
>>
>> I also wonder if there is a formal process, perhaps an ASF process, for
>> coordinating the objectives voiced in this thread with the resources
>> required to achieve them?
>>
>> For example, I believe Steve Hay has led mod_perl2 development lately,
>> versions 2.0.9 and 2.0.10, anyway. Should he be engaged, or if the leadership
>> of the project has been handed off, whoever has taken over? Do the project
>> steward(s) follow this mailing list?
>>
>> I don't mean to get in the way of positive and well-intended progress. I love
>> mod_perl and only want the best for its future development.
>>
>> But there might be other development plans in progress with which coordination
>> would be helpful.
>>
>> --
>> Read my Latest Blog Post for Telecom Pros: _Excel Telecom Tricks - Sequential
>> Numbering <https://bangkokbeachtelecom.com/sequential-numbering/>_
>> Russell Lundberg
>> Bangkok, Thailand +66 91 546 4539
>> https://bangkokbeachtelecom.com/
>> LinkedIn Profile <https://th.linkedin.com/in/russelllundberg>
>>
>>
>> On Mon, Jan 28, 2019 at 8:04 AM John Dunlap <John@lariat.co
>> <mailto:John@lariat.co>> wrote:
>>
>> I will second what Sive is saying. My organization does not have in-house
>> experience writing C code(our internal skill sets are web application and
>> database development) but we are potentially interested in sponsoring some
>> development on mod_perl with the goal of adding support for mpm_worker and
>> or mpm_event because we are interested in taking advantage of mod_http2.
>> In addition to our sponsorship, we could also assist in testing changes
>> and provided segfaults and debugging/environmental information from out
>> development and testing environments. Is anyone who is able to do this
>> kind of development interested in having a conversation with Sive and
>> myself with respect to sponsoring some development?
>>
>> On Mon, Jan 28, 2019 at 1:11 AM Sive Lindmark <sive@capestream.se
>> <mailto:sive@capestream.se>> wrote:
>>
>> Hi William!
>>
>> Count on us, my firm can sponsor work as I stated before, and also
>> contribute setting up test cases and perhaps also do some coding if we
>> have the knowledge to do whats needed.
>> My coders are not used to be part of any open source project, so we
>> can not take any leading roll though.
>>
>> How could a sponsor model work?
>>
>> I have followed crypto world for some time now, and they sometimes set
>> up price for someone thats achieve a goal. Something we can do here?
>>
>> /Sive
>>
>>
>>
>> --
>> John Dunlap
>> /CTO | Lariat/
>> /
>> /
>> /*Direct:*/
>> /john@lariat.co <mailto:john@lariat.co>/
>> /
>> *Customer Service:*/
>> 877.268.6667
>> support@lariat.co <mailto:support@lariat.co>
>>
>

Hello all,

we feel in the same situation.

We are using mod_perl mostly as users and all of our production business
activity is based and rely on perl / mod_perl.

We are able to secure finance funds, hardware and people hands( perl ,
DevOps ) to support mod_perl project and secure it's future.

I'm not familiar with the oraganisation and logsitics behind mod_perl
development,but what André Warnier propose sounds resonable.

This Feb we was at FOSDEM 2019, Belgium, I was very sad because of lag
of any serios interes, devrooms or presentaions for perl.

It was only one presentaion for perl:
https://fosdem.org/2019/schedule/event/perl11/ , author Will the Chill
Braswell.

Great Job Will.

Mod_perl is great implementation and it will be shame for all of us (
mod_perl users ) to leave it die because of all modern tendencies :)


Cheers
--
Rumen Palov
CTO
E-CARD LTD.

On 02/08/19 10:59, André Warnier (tomcat) wrote:
> I would like to add my voice to (at least) Russel's and Sive's.
> Our situation (and I understand most of the non-Perl-PMC's interventors'
> in this thread is similar) is :
> - we are interested in the future development of mod_perl, and are
> willing to "support" or "sponsor" such development
> - we understand that nobody is actively working on mod_perl currently.
> What we do not know/understand clearly is "why not ?", and how to
> possibly change this situation
> - we all have some programming resources available, but none of which
> have the current competences that we feel are necessary to undertake
> such development efficiently in the short term. That is because our
> organisations are mostly *users* of mod_perl, in the course of our main
> activity, which is to develop end-user-oriented application software, of
> which a part is currently based on Apache and mod_perl.
> - we know that there are people in the mod_perl PMC which do have such
> competences. We do not know about their practical
> availability/willingness to do so.
> - we have no hands-on experience of such kinds of open-source, "free"
> development projects, and we do not really know "what makes them tick"
> - we all have some form of possible contribution in mind and among our
> possibilities, but so far, short apparently of providing ourselves some
> qualified programming staff to do the work (as Adam mentions below, and
> William did before him), it does not seem that there is any obvious
> avenue open to do so.
>
> To wrap this up somewhat naively and roughly : if we just wanted to pour
> some money in such a project, to revive the interest of the current
> group of people which do have the competences and experience to work on
> this efficiently, how would we go about it ?
> Or is this not possible/practical/sufficient ?
> Could someone of the mod_perl PMC (or the Apache Foundation) take the
> lead about something like this, and somehow ask the right questions, and
> put together a proposal that could lead to such a "revival" of the
> Apache/mod_perl project ?
> I believe that we could all collectively start by making a financial
> contribution to such a preliminary effort, if that is also what it takes
> to get it going.
>
>
>
> On 07.02.2019 03:39, Adam Prime wrote:
>> I can tell you that at least some of the PMC members are on this list.
>> But I can
>> also tell you that there is essentially no development going on right
>> now. The
>> PMC is essentially idle, and there aren't any plans to do anything
>> with regards
>> to improving support for newer MPM's. That said, the project is open
>> source, and
>> if there are people or companies out there with the skills and desire
>> to work on
>> those features, things can get merged, and people can get added to the
>> PMC, or
>> as project commiters to enable that.
>>
>> Adam
>>
>>
>> On 1/28/19 1:30 PM, Russell Lundberg wrote:
>>> As a long-time fan and user of mod_perl, I like so much the way this
>>> conversation is turning.
>>>
>>> I also wonder if there is a formal process, perhaps an ASF process, for
>>> coordinating the objectives voiced in this thread with the resources
>>> required to achieve them?
>>>
>>> For example, I believe Steve Hay has led mod_perl2 development lately,
>>> versions 2.0.9 and 2.0.10, anyway. Should he be engaged, or if the
>>> leadership
>>> of the project has been handed off, whoever has taken over?  Do the
>>> project
>>> steward(s) follow this mailing list?
>>>
>>> I don't mean to get in the way of positive and well-intended
>>> progress. I love
>>> mod_perl and only want the best for its future development.
>>>
>>> But there might be other development plans in progress with which
>>> coordination
>>> would be helpful.
>>>
>>> --
>>> Read my Latest Blog Post for Telecom Pros: _Excel Telecom Tricks -
>>> Sequential
>>> Numbering <https://bangkokbeachtelecom.com/sequential-numbering/>_
>>> Russell Lundberg
>>> Bangkok, Thailand +66 91 546 4539
>>> https://bangkokbeachtelecom.com/
>>> LinkedIn Profile <https://th.linkedin.com/in/russelllundberg>
>>>
>>>
>>> On Mon, Jan 28, 2019 at 8:04 AM John Dunlap <John@lariat.co
>>> <mailto:John@lariat.co>> wrote:
>>>
>>>     I will second what Sive is saying. My organization does not have
>>> in-house
>>>     experience writing C code(our internal skill sets are web
>>> application and
>>>     database development) but we are potentially interested in
>>> sponsoring some
>>>     development on mod_perl with the goal of adding support for
>>> mpm_worker and
>>>     or mpm_event because we are interested in taking advantage of
>>> mod_http2.
>>>     In addition to our sponsorship, we could also assist in testing
>>> changes
>>>     and provided segfaults and debugging/environmental information
>>> from out
>>>     development and testing environments. Is anyone who is able to do
>>> this
>>>     kind of development interested in having a conversation with Sive
>>> and
>>>     myself with respect to sponsoring some development?
>>>
>>>     On Mon, Jan 28, 2019 at 1:11 AM Sive Lindmark <sive@capestream.se
>>>     <mailto:sive@capestream.se>> wrote:
>>>
>>>         Hi William!
>>>
>>>         Count on us, my firm can sponsor work as I stated before, and
>>> also
>>>         contribute setting up test cases and perhaps also do some
>>> coding if we
>>>         have the knowledge to do whats needed.
>>>         My coders are not used to be part of any open source project,
>>> so we
>>>         can not take any leading roll though.
>>>
>>>         How could a sponsor model work?
>>>
>>>         I have followed crypto world for some time now, and they
>>> sometimes set
>>>         up price for someone thats achieve a goal. Something we can
>>> do here?
>>>
>>>         /Sive
>>>
>>>
>>>
>>>     --
>>>     John Dunlap
>>>     /CTO | Lariat/
>>>     /
>>>     /
>>>     /*Direct:*/
>>>     /john@lariat.co <mailto:john@lariat.co>/
>>>     /
>>>     *Customer Service:*/
>>>     877.268.6667
>>>     support@lariat.co <mailto:support@lariat.co>
>>>
>>
>
>

Hi!

about André’s post, I agree 100 % .

> I believe that we could all collectively start by making a financial contribution to such a preliminary effort, if that is also what it takes to get it going.
yes!!

Sive