httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Date Mon, 13 Jan 2003 02:29:33 GMT
Eli Marmor wrote:
> Let me continue the idea that I raised in the past, because I believe
> it may help convince ASF to adopt apreq into the main source tree:
> 
> We should separate the code to two layers; The lower will depend only
> on APR/APR-UTIL, and not on Apache. For example, it will contain the
> parsing of parameters. The APR/APR-UTIL developers will be happy to
> adopt it, because it is thin on one hand, yet makes APR a strong
> library for anybody: CGI-BIN developers, FastCGI, etc. It is pity that
> a library like APR with so much potential, is wasted today, just
> because it doesn't have any real benefit outside Apache (I think that
> there is only ONE project - subversion - that uses it except for
> Apache). The lower layer of apreq is just the missing piece that may
> make APR a real killer.
> 
> The higher layer will be built on the lower one and use it. It will
> contain all the stuff that is Apache-dependent, such as reading from
> and writing to bucket/brigades. After the lower layer was added to APR,
> it will be easier to convince the members to adopt it too (to httpd of
> course, not to APR). Maybe it should be even a part of the core (and
> not just a yet another module), or at least a "must" module, so other
> modules can use it without caring if it was compiled-in and enabled.

We have offered to do whatever changes required to get the lib into the 
core. However the idea wasn't accepted. So it'd be silly to spend time 
on something that won't help the library to get accepted into the core, 
because there are so many other things that still weren't ported to 2.0.

Therefore currently the goal is to complete the library porting to 2.0, 
so the glues for other languages could be written. If I undestand well 
what you are offerring, this can happen internally without affecting the 
external API. So if anybody is interested in doing a further layering 
(because they have the need for it or just for fun) they are welcome to 
do so, once the new repository is created and populated.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Mime
View raw message