Re: starting apreq 2.0

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

Stas Bekman <st...@stason.org> writes:

> OK, let's start working on the porting plan. Since I'm not familiar with 
> apreq-1.0 internals I'll try to catch up as we go.
> 
> The first issues is are infrastructure questions:
> 
> - should apreq-2.0 cvs rep be created, similar to modperl-2.0 and httpd-2.0?
> 
> - Should there be a separate set of mailing lists? (Since I've just 
> joined I don't know how heavy is the traffic and whether it worth the 
> split). Since httpd and modperl didn't I guess there is no need for a 
> new dev list, though may be we need a new -cvs list. apreq-2.0-cvs?

I think keeping discussion of 2.0 here is best; this list is typically
very low traffic for the current libapreq.  I don't have any strong
opinions about the best way to go with the cvs tree.  There's still
a lot of work to do for the current apreq; but I think it's mainly
maintenance and QA issues like e.g. adding a simple and portable 
test suite.

> Since I'm mostly interested in Apache::Request for modperl-2.0, and may 
> be it's best discussed on the modperl dev list, but should 
> Apache::Request (the Perl glue) be an integral part of mod_perl? Or as 
> an add-on module, like it is now? I guess we could make it a part of 
> mod_perl if apreq was distributed together with httpd.

My real preference would be to move the perl stuff into mod_perl and
the C stuff into httpd (parallel to what's done with expat in apache
1.3*).  I've already patched 1.23 for apreq support by parroting the
expat config and put it online:

  http://httpd.apache.org/~joes/apache.tar.gz

AFAICT it works just great that way; but we might consider linking
apreq as a shared library instead (or perhaps user-configurable to be
shared, static, or simply non-existent :).

> I want Apache::Request (not libapreq) to be a part of modperl-2.0, 
> because it features WrapXS which makes it very easy to write XS wrappers 
> for the C APIs. Gerald started working on splitting WrapXS into its own 
> project so it could be reused outside modperl build, but I didn't hear 
> the status update for a long time.

I don't know about Gerald's work, but straight XS is pretty easy as 
it is.  The XS documentation is crap but that's another story :)  What 
makes the current Apache::Request complicated is the wacky platform-
specific perl configurations and vendor-munged installations of mod_perl
that are out there.

> In any case I think we could make the Perl/XS code as a part of modperl 
> and build it if libapreq is installed.

Agreed, but I'd like to see our (future) work on the C API get bundled 
somehow into the standard apache distribution; shipping a separate libapreq
extension library IMO overcomplicates things for an end-user.  I think
they should be able to "turn on" apreq in their apache source tree and
then configure mod_whatever to just use it.

-- 
Joe Schaefer

Re: starting apreq 2.0

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

Stas Bekman <st...@stason.org> writes:

> I guess you haven't seen what Doug has done to modperl 2.0, regarding 
> mapping C code to Perl :) It's so slick! Almost no code to glue a huge API.

No, I haven't.  I've tried to remain completely 2.* ignorant until now.
I do need to spend some time getting up to speed with both apache and modperl.

> >>In any case I think we could make the Perl/XS code as a part of modperl 
> >>and build it if libapreq is installed.
> >>
> > 
> > Agreed, but I'd like to see our (future) work on the C API get bundled 
> > somehow into the standard apache distribution; shipping a separate libapreq
> > extension library IMO overcomplicates things for an end-user.  I think
> > they should be able to "turn on" apreq in their apache source tree and
> > then configure mod_whatever to just use it.
> 
> OK, so let's do things one by one, can you please ask httpd-dev list to 
> consider to include apreq in httpd distro? Once we resolve this issue, 
> it's makes things easier.

If we're talking about apreq 2.0, I'm more than a little uncomfortable 
asking for the httpd-dev folks to include our work without having
anything to show them.  In any case, I'd like to hear what others, and
especially Jim, think about the direction we should take with respect
to distribution of the C library.

-- 
Joe Schaefer

Re: starting apreq 2.0

[Stas Bekman <st...@stason.org>]

 >>want Apache::Request (not libapreq) to be a part of modperl-2.0,

>>because it features WrapXS which makes it very easy to write XS wrappers 
>>for the C APIs. Gerald started working on splitting WrapXS into its own 
>>project so it could be reused outside modperl build, but I didn't hear 
>>the status update for a long time.
>>
> 
> I don't know about Gerald's work, but straight XS is pretty easy as 
> it is.  The XS documentation is crap but that's another story :)  What 
> makes the current Apache::Request complicated is the wacky platform-
> specific perl configurations and vendor-munged installations of mod_perl
> that are out there.


I guess you haven't seen what Doug has done to modperl 2.0, regarding 
mapping C code to Perl :) It's so slick! Almost no code to glue a huge API.


>>In any case I think we could make the Perl/XS code as a part of modperl 
>>and build it if libapreq is installed.
>>
> 
> Agreed, but I'd like to see our (future) work on the C API get bundled 
> somehow into the standard apache distribution; shipping a separate libapreq
> extension library IMO overcomplicates things for an end-user.  I think
> they should be able to "turn on" apreq in their apache source tree and
> then configure mod_whatever to just use it.

OK, so let's do things one by one, can you please ask httpd-dev list to 
consider to include apreq in httpd distro? Once we resolve this issue, 
it's makes things easier.

_____________________________________________________________________
Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker
http://stason.org/      mod_perl Guide   http://perl.apache.org/guide
mailto:stas@stason.org  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/