httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Marmor <mar...@netmask.it>
Subject Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Date Mon, 13 Jan 2003 08:25:24 GMT
Joe Schaefer wrote:

> It's not easy to convince people of something without first
> involving them in the discussion.  Stas tried; I tried.
> Maybe three's a charm.  I wish you the best of luck.

I know, I know...
And I've already experienced that.
In addition, as a lurker of that list, I've already witnessed several
cases of others (you mentioned one of them - "El-Kabong").

I just hope that it will be easier with APR/APR-UTIL.
Because apreq is not only based on APR/APR-UTIL, but does things that
APR/APR-UTIL must have, like parsing a parameters string.

Then, after integrating the lower level parts of apreq into APR, it
may be easier to discuss the integration of the higher parts into
httpd.

> If you're serious about making apreq-2 operate sans-httpd,
> by all means do it.  Just don't do it for apr/httpd's sake,
> because their lack of enthusiasm about apreq-2 will probably
> just frustrate you.  It sure frustrates me.
> 
> So, do it for *our* users instead.  At the very least it would
> lead to a nice set of unit tests for apreq-2, since you'll have
> to write those to prove it actually works.  And if it does work,
> it will definitely go into *our* distribution.

Relax ;-)
*IF* I do it (spare time matters...), I will do it neither for them
NOR for our users, but for me (well, I guess that my own benefit will
be very minor in comparison with the benefit of all the users, but it
is enough to justify such an effort).

And I think not only about CGI-BIN authors or FastCGI, but also about
module authors:
I developed a layer that emulates the basic functionality of the
filters, so simple modules can be tested/profiled standalone, without
being attached to Apache (it is very ugly and works only with limited
modules, so I'm afraid to publish source code...).

Such modules can be linked to the lower level of apreq too, once it is
separated (well, I can also improve my filtering emulation...  but I
prefer this way...).

Ehhhh....  and something else:
I wrote that not only the internal structure will have to change, but
also the API;
After thinking about it a little more, I think that it can be done in
a way that will keep backward compatibility.

In any case, I don't do anything before having a more up-to-date
version of apreq-2 (my current one is from August).

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

Mime
View raw message