Re: Was there any concrete decision on apreq?

[Joseph Schaefer <jo...@yahoo.com>]

In a nutshell the long term goal has always been to get the c parts of apreq incorporated into httpd distributions so the perl parts can ship with modperl.  This is still along those lines.  In order to continue to expose the cool cgi code that Issac added to libapreq we need to ensure there is an actual external library still when we ship with httpd otherwise we lose the modular features we spent so much time designing as apreq would then be limited to httpd modules only.  I'd like to see it serve the entire gamut of web apps including fast cgi.  That's what my ongoing plans are for the httpd project.

Sent from my iPhone

> On Feb 24, 2015, at 8:53 AM, Steve Hay <st...@googlemail.com> wrote:
> 
> I'm not sure exactly what the proposal here is, but as long as the
> perl glue (Apache2::Request et al) still exists on CPAN and can be
> built in the usual manner then that sounds fine.
> 
> At the moment it contains a number of XS modules (APR::Request::*)
> which variously link against libapreq2.lib (.dll) and mod_apreq2.lib
> (.so), which are also built as part of the same build process. If
> those XS modules will in the future link against httpd (libhttpd.lib?)
> instead then I can't think of any problem with that.
> 
> 
>> On 24 February 2015 at 11:02, Issac Goldstand <ma...@beamartyr.net> wrote:
>> I think nothing.
>> 
>> Most mod_perl users (I think) install apreq via Apache2::Request.  That
>> can continue to be maintained on CPAN, as is, linking against httpd
>> instead of mod_apreq
>> 
>> Or do you forsee a problem here?
>> 
>>> On 2/24/2015 9:56 AM, Steve Hay wrote:
>>> What would this mean for mod_perl users? I, and I assume many
>>> others(?), still use the perl glue part of libapreq in mod_perl
>>> software.
>>> 
>>> I only just spotted this thread, and just wondered how such mod_perl
>>> users will be affected, if at all.
>>> 
>>>> On 24 February 2015 at 03:24, Joseph Schaefer <jo...@yahoo.com> wrote:
>>>> I still want to do that just lacking tuits
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>>> On Feb 23, 2015, at 3:56 PM, Eric Covener <co...@gmail.com> wrote:
>>>>>> 
>>>>>> On Mon, Feb 23, 2015 at 3:45 PM, Gregg Smith <gl...@gknw.net> wrote:
>>>>>> Am I missing something? Did I miss a boatload of email where any firm
>>>>>> decision was made?
>>>>> 
>>>>> 
>>>>> I don't think you have missed anything. I assume very few people have
>>>>> any clue how it's integrated/used today.  The last thing I have in my
>>>>> mail archive is joes proposal to pull the library part back out and
>>>>> make it available in a way similar to mod_ldap.
>> 

Re: Was there any concrete decision on apreq?

["Victor J. Orlikowski" <vi...@alumni.duke.edu>]

On Mar 8, 2015, at 11:46 AM, Graham Leggett <mi...@sharp.fm> wrote:
> 
> For ages library functions for httpd have ended up in APR, but this isn’t ideal - APR is a portability layer, and even though code is being accepted that “works with APR”, in reality we really need a libhttpd library that can provide “web server like stuff” in a proper true library form. Will certainly make tools in the “support” area of the httpd tree easier to develop for, as none of the tools have access to httpd proper, and code must be cut and pasted.
> 
> I don’t like that apreq as a loadable module, but I would love it as a proper shared library.
> 
> Same with the expressions code.

+1

Best,
Victor
--
Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu

Re: Was there any concrete decision on apreq?

[Joe Schaefer <jo...@yahoo.com>]

apreq is really both Graham, a httpd module and a library.But what I'd like to see is the apreq stuff in the server'score put into a separate library and have either httpd orthe apreq module link to it.
Unfortunately the existing build system for apreq is automakebased, and I don't have much knowledge right now about howto build a dll from httpd's build system.  Other people do obviously,I mean apr does it, it's just not something I immediately grok.
 

     On Sunday, March 8, 2015 11:48 AM, Graham Leggett <mi...@sharp.fm> wrote:
   

 On 08 Mar 2015, at 9:11 AM, Joseph Schaefer <jo...@yahoo.com> wrote:

> In a nutshell the long term goal has always been to get the c parts of apreq incorporated into httpd distributions so the perl parts can ship with modperl.  This is still along those lines.  In order to continue to expose the cool cgi code that Issac added to libapreq we need to ensure there is an actual external library still when we ship with httpd otherwise we lose the modular features we spent so much time designing as apreq would then be limited to httpd modules only.  I'd like to see it serve the entire gamut of web apps including fast cgi.  That's what my ongoing plans are for the httpd project.

+1.

For ages library functions for httpd have ended up in APR, but this isn’t ideal - APR is a portability layer, and even though code is being accepted that “works with APR”, in reality we really need a libhttpd library that can provide “web server like stuff” in a proper true library form. Will certainly make tools in the “support” area of the httpd tree easier to develop for, as none of the tools have access to httpd proper, and code must be cut and pasted.

I don’t like that apreq as a loadable module, but I would love it as a proper shared library.

Same with the expressions code.

Regards,
Graham
—


   

RE: Was there any concrete decision on apreq?

[Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>]

> -----Original Message-----
> From: Graham Leggett [mailto:minfrin@sharp.fm]
> Sent: Sonntag, 8. März 2015 16:47
> To: dev@httpd.apache.org
> Cc: apreq-dev@httpd.apache.org
> Subject: Re: Was there any concrete decision on apreq?
> 
> On 08 Mar 2015, at 9:11 AM, Joseph Schaefer <jo...@yahoo.com>
> wrote:
> 
> > In a nutshell the long term goal has always been to get the c parts of
> apreq incorporated into httpd distributions so the perl parts can ship
> with modperl.  This is still along those lines.  In order to continue to
> expose the cool cgi code that Issac added to libapreq we need to ensure
> there is an actual external library still when we ship with httpd
> otherwise we lose the modular features we spent so much time designing as
> apreq would then be limited to httpd modules only.  I'd like to see it
> serve the entire gamut of web apps including fast cgi.  That's what my
> ongoing plans are for the httpd project.
> 
> +1.
> 
> For ages library functions for httpd have ended up in APR, but this isn’t
> ideal - APR is a portability layer, and even though code is being accepted
> that “works with APR”, in reality we really need a libhttpd library that
> can provide “web server like stuff” in a proper true library form. Will
> certainly make tools in the “support” area of the httpd tree easier to
> develop for, as none of the tools have access to httpd proper, and code
> must be cut and pasted.
> 
> I don’t like that apreq as a loadable module, but I would love it as a
> proper shared library.
> 
> Same with the expressions code.

+1

Sounds sensible.

Regards

Rüdiger

RE: Was there any concrete decision on apreq?

[Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>]

> -----Original Message-----
> From: Graham Leggett [mailto:minfrin@sharp.fm]
> Sent: Sonntag, 8. März 2015 16:47
> To: dev@httpd.apache.org
> Cc: apreq-dev@httpd.apache.org
> Subject: Re: Was there any concrete decision on apreq?
> 
> On 08 Mar 2015, at 9:11 AM, Joseph Schaefer <jo...@yahoo.com>
> wrote:
> 
> > In a nutshell the long term goal has always been to get the c parts of
> apreq incorporated into httpd distributions so the perl parts can ship
> with modperl.  This is still along those lines.  In order to continue to
> expose the cool cgi code that Issac added to libapreq we need to ensure
> there is an actual external library still when we ship with httpd
> otherwise we lose the modular features we spent so much time designing as
> apreq would then be limited to httpd modules only.  I'd like to see it
> serve the entire gamut of web apps including fast cgi.  That's what my
> ongoing plans are for the httpd project.
> 
> +1.
> 
> For ages library functions for httpd have ended up in APR, but this isn’t
> ideal - APR is a portability layer, and even though code is being accepted
> that “works with APR”, in reality we really need a libhttpd library that
> can provide “web server like stuff” in a proper true library form. Will
> certainly make tools in the “support” area of the httpd tree easier to
> develop for, as none of the tools have access to httpd proper, and code
> must be cut and pasted.
> 
> I don’t like that apreq as a loadable module, but I would love it as a
> proper shared library.
> 
> Same with the expressions code.

+1

Sounds sensible.

Regards

Rüdiger

Re: Was there any concrete decision on apreq?

[Joe Schaefer <jo...@yahoo.com>]

apreq is really both Graham, a httpd module and a library.But what I'd like to see is the apreq stuff in the server'score put into a separate library and have either httpd orthe apreq module link to it.
Unfortunately the existing build system for apreq is automakebased, and I don't have much knowledge right now about howto build a dll from httpd's build system.  Other people do obviously,I mean apr does it, it's just not something I immediately grok.
 

     On Sunday, March 8, 2015 11:48 AM, Graham Leggett <mi...@sharp.fm> wrote:
   

 On 08 Mar 2015, at 9:11 AM, Joseph Schaefer <jo...@yahoo.com> wrote:

> In a nutshell the long term goal has always been to get the c parts of apreq incorporated into httpd distributions so the perl parts can ship with modperl.  This is still along those lines.  In order to continue to expose the cool cgi code that Issac added to libapreq we need to ensure there is an actual external library still when we ship with httpd otherwise we lose the modular features we spent so much time designing as apreq would then be limited to httpd modules only.  I'd like to see it serve the entire gamut of web apps including fast cgi.  That's what my ongoing plans are for the httpd project.

+1.

For ages library functions for httpd have ended up in APR, but this isn’t ideal - APR is a portability layer, and even though code is being accepted that “works with APR”, in reality we really need a libhttpd library that can provide “web server like stuff” in a proper true library form. Will certainly make tools in the “support” area of the httpd tree easier to develop for, as none of the tools have access to httpd proper, and code must be cut and pasted.

I don’t like that apreq as a loadable module, but I would love it as a proper shared library.

Same with the expressions code.

Regards,
Graham
—


   

Re: Was there any concrete decision on apreq?

["Victor J. Orlikowski" <vi...@alumni.duke.edu>]

On Mar 8, 2015, at 11:46 AM, Graham Leggett <mi...@sharp.fm> wrote:
> 
> For ages library functions for httpd have ended up in APR, but this isn’t ideal - APR is a portability layer, and even though code is being accepted that “works with APR”, in reality we really need a libhttpd library that can provide “web server like stuff” in a proper true library form. Will certainly make tools in the “support” area of the httpd tree easier to develop for, as none of the tools have access to httpd proper, and code must be cut and pasted.
> 
> I don’t like that apreq as a loadable module, but I would love it as a proper shared library.
> 
> Same with the expressions code.

+1

Best,
Victor
--
Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu

Re: Was there any concrete decision on apreq?

[Graham Leggett <mi...@sharp.fm>]

On 08 Mar 2015, at 9:11 AM, Joseph Schaefer <jo...@yahoo.com> wrote:

> In a nutshell the long term goal has always been to get the c parts of apreq incorporated into httpd distributions so the perl parts can ship with modperl.  This is still along those lines.  In order to continue to expose the cool cgi code that Issac added to libapreq we need to ensure there is an actual external library still when we ship with httpd otherwise we lose the modular features we spent so much time designing as apreq would then be limited to httpd modules only.  I'd like to see it serve the entire gamut of web apps including fast cgi.  That's what my ongoing plans are for the httpd project.

+1.

For ages library functions for httpd have ended up in APR, but this isn’t ideal - APR is a portability layer, and even though code is being accepted that “works with APR”, in reality we really need a libhttpd library that can provide “web server like stuff” in a proper true library form. Will certainly make tools in the “support” area of the httpd tree easier to develop for, as none of the tools have access to httpd proper, and code must be cut and pasted.

I don’t like that apreq as a loadable module, but I would love it as a proper shared library.

Same with the expressions code.

Regards,
Graham
—

Re: Was there any concrete decision on apreq?

[Graham Leggett <mi...@sharp.fm>]

On 08 Mar 2015, at 9:11 AM, Joseph Schaefer <jo...@yahoo.com> wrote:

> In a nutshell the long term goal has always been to get the c parts of apreq incorporated into httpd distributions so the perl parts can ship with modperl.  This is still along those lines.  In order to continue to expose the cool cgi code that Issac added to libapreq we need to ensure there is an actual external library still when we ship with httpd otherwise we lose the modular features we spent so much time designing as apreq would then be limited to httpd modules only.  I'd like to see it serve the entire gamut of web apps including fast cgi.  That's what my ongoing plans are for the httpd project.

+1.

For ages library functions for httpd have ended up in APR, but this isn’t ideal - APR is a portability layer, and even though code is being accepted that “works with APR”, in reality we really need a libhttpd library that can provide “web server like stuff” in a proper true library form. Will certainly make tools in the “support” area of the httpd tree easier to develop for, as none of the tools have access to httpd proper, and code must be cut and pasted.

I don’t like that apreq as a loadable module, but I would love it as a proper shared library.

Same with the expressions code.

Regards,
Graham
—