Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Sender: root@localhost.localdomain
Message-ID: <3E2224E6.770C6FF8@netmask.it>
Date: Mon, 13 Jan 2003 04:31:02 +0200
From: Eli Marmor <marmor@netmask.it>
Organization: Netmask (El-Mar) Internet Technologies
MIME-Version: 1.0
To: apreq list <apreq-dev@httpd.apache.org>
Subject: Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
References: <B4ADD185-241D-11D7-9D0E-0003931A964A@wheeler.net>
 <m3adia9d4e.fsf@mumonkan.sunstarsys.com>
 <m3u1gh8ox5.fsf_-_@mumonkan.sunstarsys.com> <3E1F7C59.9090506@stason.org>
 <m3k7hc7xeq.fsf@mumonkan.sunstarsys.com> <3E20C97A.2020200@stason.org>
 <m3k7hbjdyt.fsf@mumonkan.sunstarsys.com> <3E20D9FB.9010304@stason.org>
 <3E221E7E.1479672@netmask.it> <3E22248D.9080301@stason.org>
Content-Type: text/plain; charset=iso-8859-8
Content-Transfer-Encoding: 7bit

Stas Bekman wrote:

> 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.

Theoretically, you are right. But practically - no.

For example: There are functions that should belong to the lower layer,
but currently get request_rec as a parameter.

So the separation that I'm talking about, is not only internal.

However, I still believe that it is not too complex.

> 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.

-- 
Eli Marmor
marmor@netmask.it
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__________________________________________________________
Tel.:   +972-9-766-1020          8 Yad-Harutzim St.
Fax.:   +972-9-766-1314          P.O.B. 7004
Mobile: +972-50-23-7338          Kfar-Saba 44641, Israel