httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: starting apreq 2.0
Date Wed, 30 Jan 2002 10:30:59 GMT
Stas Bekman <> 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:

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

View raw message