You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2003/01/08 06:07:15 UTC
1.1_rc4
The current cvs is rc4; please test that
it's OK:
http://www.apache.org/~joes/libapreq-1.1_rc4.tar.gz
Assuming Sven Geisler OK's it, I'm +1
for releasing it as 1.1.
Thanks for all the help, folks! It's
really great that we've now got OS X
support, and the Perl API is now segfault
free w/ 5.8 (fingers crossed :-).
--
Joe Schaefer
Re: 1.1_rc4
Posted by Sven Geisler <sg...@aeccom.com>.
Hi Joe,
I have no more segfaults after a few request (~ 1600) and multiple tries
to reproduce the known segfaults.
Do you mean with next version libapreq for mod_perl 2 or do you plan a
version 1.2?
I guess, I can suggest some ideas for the API after reviewing of my
code.
Sven.
Am Mit, 2003-01-08 um 06.07 schrieb Joe Schaefer:
> The current cvs is rc4; please test that
> it's OK:
>
> http://www.apache.org/~joes/libapreq-1.1_rc4.tar.gz
>
> Assuming Sven Geisler OK's it, I'm +1
> for releasing it as 1.1.
>
> Thanks for all the help, folks! It's
> really great that we've now got OS X
> support, and the Perl API is now segfault
> free w/ 5.8 (fingers crossed :-).
>
> --
> Joe Schaefer
>
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Stas Bekman <st...@stason.org>.
Eli Marmor wrote:
[...]
> The only justification of requiring the request_rec is the pool.
> So we can move the code of the function to a sub-function (called
> "apr_request_new") and leave only the following in the original
> function:
[...]
you do need the pool variable because we now use that much cleaner way to
allocate memory in apreq-2.0. So instead of requiring request_rec, the API
could ask directly for the pool. That pool can be easily created by other
apps (not httpd) since apr will be already linked in.
So I suppose what you suggest (in this example) is to use only the really
needed elements in the API, rather than passing more app-specific objects,
which is the case with request_rec.
__________________________________________________________________
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
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Eli Marmor <ma...@netmask.it>.
Issac Goldstand wrote:
> Eli,
> Could you elaborate a bit on exactly what you would consider to be
> high-level and what low-level? Are you trying to say that we could make
> low-level parsers which could, for example, be plugged into an SMTP module
> for Apache to look at MIME encoded messages using the same "low-level" code
> as HTTP's multipart forms? I hope I'm on the right track here, and if so, I
> like the idea. But could you think of a good list of items to be put in the
> high-level and a list for the low-level?
I don't have an existing list, but the following example may clear my
idea:
Let's take apreq_request_new (I use the terminology of apreq-2):
The only justification of requiring the request_rec is the pool.
So we can move the code of the function to a sub-function (called
"apr_request_new") and leave only the following in the original
function:
apreq_request_t *apreq_request_new(request_rec *r)
{
return apr_request_new(r->pool);
}
(some of the fields of request_rec, like args and the headers, will
have to be passed by the higher level functions to the lower level
ones, or - alternatively - to be added to apreq_request_t).
Of course, this is a simple example. Sometimes, it may be trickier.
Especially in cases like multipart POSTs, where the parsing and
handling is needed in APR (i.e. CGI, FastCGI, etc.), but the reading
of the block (or - more precisely - reading from the input filter) -
should be left to the higher level.
But it is still easier than the effort of porting to Apache-2; Contrary
to THAT effort, most of the work here is copy-paste...
--
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
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Issac Goldstand <ma...@beamartyr.net>.
Eli,
Could you elaborate a bit on exactly what you would consider to be
high-level and what low-level? Are you trying to say that we could make
low-level parsers which could, for example, be plugged into an SMTP module
for Apache to look at MIME encoded messages using the same "low-level" code
as HTTP's multipart forms? I hope I'm on the right track here, and if so, I
like the idea. But could you think of a good list of items to be put in the
high-level and a list for the low-level?
Issac
----- Original Message -----
From: "Eli Marmor"
Subject: Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
> 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
>
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Eli Marmor <ma...@netmask.it>.
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
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Stas Bekman <st...@stason.org>.
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
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Issac Goldstand <ma...@beamartyr.net>.
I'm thinking that while apreq is going to be difficult to get into the main
httpd source tree, perhaps we might find it easier to convince them to adopt
some of the functions (I think what Eli referred to as "low-level functions"
in a previous email) as part of the apr-utils package. I could see it
fitting in there...
Issac
----- Original Message -----
From: "Joe Schaefer" <jo...@sunstarsys.com>
To: "Eli Marmor" <ma...@netmask.it>
Cc: "apreq list" <ap...@httpd.apache.org>
Sent: Monday, January 13, 2003 6:30 AM
Subject: Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
> Eli Marmor <ma...@netmask.it> writes:
>
> > 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:
>
> 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.
>
> > We should separate the code to two layers; The lower will depend only
> > on APR/APR-UTIL,
>
> There was talk recently on dev@ about moving apr_buckets out of
> apr-util and into httpd. If that happens it'd be a shame, but
> sometimes thems the breaks.
>
> 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.
>
> --
> Joe Schaefer
>
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Eli Marmor <ma...@netmask.it> writes:
> Joe Schaefer wrote:
[...]
> > 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).
Of course. But what I'm trying to express to you is this:
If you're arguing for a redesign of apreq, it is no longer
compelling to say things like "do it this way, so project-X
will incorporate it into their distribution". BTDTGTTS.
The case you need to make *here* is that such changes
would benefit the apreq-2 distribution itself, because
that's what *our* users will care about.
You could make a great start at that by just designing an
abstract environment for apreq_cookies to live in. You basically
just need to develop abstractions for "bake" and "parse". What
I would suggest is adding an "env" vtable to apreq_cookie:
struct apreq_cookie_env_t {
/* apreq_cookie to server header vtable */
/* some function pointers */
*parse;
*bake;
/* maybe a pool, etc */
}
> 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...).
Very cool- keep it handy so we can bang on it here (eventually).
[...]
> 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).
OK.
--
Joe Schaefer
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Eli Marmor <ma...@netmask.it>.
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
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Eli Marmor <ma...@netmask.it> writes:
> 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:
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.
> We should separate the code to two layers; The lower will depend only
> on APR/APR-UTIL,
There was talk recently on dev@ about moving apr_buckets out of
apr-util and into httpd. If that happens it'd be a shame, but
sometimes thems the breaks.
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.
--
Joe Schaefer
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Eli Marmor <ma...@netmask.it>.
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
the new 2.0 cvs rep is available
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Joe Schaefer wrote:
>
>> Stas Bekman <st...@stason.org> writes:
>>
>> [...]
>>
>>
>>> We all agree that waiting for httpd people to give a grace is a
>>> complete waste of time. I suggest that we ask Brian Behlendorf to
>>> create the apreq-2.0 repository and start working there. It's
>>> important for preserving the history of changes. I see no reason why
>>> not to do it *now*. Having a repository doesn't mean having a
>>> production version of the code.
>>
>>
>>
>> Yes, agreed- that would be best. Unfortunately, according to
>> /home/cvs/README, the first step in creating a new cvs repository is:
>>
>> (a) Get permission from your PMC. The PMC must approve the addition
>> of any repository and should be contacted through the normal means.
>>
>> That puts us back at square one, since (I think) our PMC is httpd. I
>> haven't yet lowered my self-esteem enough to now beg them for a new
>> repository to begin our work.
>> If there's a way to make things happen within our existing repository,
>> that'd be a lot less painful for me to endure. At least then, it's
>> just technical obstacles that we will face.
>
>
> Let me run this through the asf members list. I have no clue what's the
> status of the apreq project is. I thought it was a standalone project
> with its own pmc. Hopefully this can be resolved quickly.
>
> I pretty much doubt anybody at httpd will be against creating a new
> apreq-2.0 rep. or is it httpd-apreq-2.0?
Thanks to Brian Behlendorf (and silence from the httpd pmc ;) we now have
a new shiny toy to play with: the httpd-apreq-2 cvs rep.
You want to apreq-cvs-subscribe@httpd.apache.org to see Joe play with it.
(that's the same list, the httpd-apreq commits go to).
__________________________________________________________________
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
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>We all agree that waiting for httpd people to give a grace is a complete
>>waste of time. I suggest that we ask Brian Behlendorf to create the
>>apreq-2.0 repository and start working there. It's important for
>>preserving the history of changes. I see no reason why not to do it
>>*now*. Having a repository doesn't mean having a production version of
>>the code.
>
>
> Yes, agreed- that would be best. Unfortunately, according to
> /home/cvs/README, the first step in creating a new cvs repository is:
>
> (a) Get permission from your PMC. The PMC must approve the addition
> of any repository and should be contacted through the normal means.
>
> That puts us back at square one, since (I think) our PMC is httpd.
> I haven't yet lowered my self-esteem enough to now beg them for a
> new repository to begin our work.
>
> If there's a way to make things happen within our existing
> repository, that'd be a lot less painful for me to endure.
> At least then, it's just technical obstacles that we will face.
Let me run this through the asf members list. I have no clue what's the
status of the apreq project is. I thought it was a standalone project
with its own pmc. Hopefully this can be resolved quickly.
I pretty much doubt anybody at httpd will be against creating a new
apreq-2.0 rep. or is it httpd-apreq-2.0?
__________________________________________________________________
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
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> We all agree that waiting for httpd people to give a grace is a complete
> waste of time. I suggest that we ask Brian Behlendorf to create the
> apreq-2.0 repository and start working there. It's important for
> preserving the history of changes. I see no reason why not to do it
> *now*. Having a repository doesn't mean having a production version of
> the code.
Yes, agreed- that would be best. Unfortunately, according to
/home/cvs/README, the first step in creating a new cvs repository is:
(a) Get permission from your PMC. The PMC must approve the addition
of any repository and should be contacted through the normal means.
That puts us back at square one, since (I think) our PMC is httpd.
I haven't yet lowered my self-esteem enough to now beg them for a
new repository to begin our work.
If there's a way to make things happen within our existing
repository, that'd be a lot less painful for me to endure.
At least then, it's just technical obstacles that we will face.
--
Joe Schaefer
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
>>I don't see any reason why not to create a whole new rep, like all
>>other projects do. Unless you plan to have this one only temporary
>>till the destiny of apreq2 is cleared up.
>
>
> That's my plan: to make apreq-2/ (for now) a *temporary*
> location for apreq-2 development. The directory structure I
> have in mind looks something like this:
>
> apreq-2/
>
> httpd/ (server support for apreq-2)
>
> c/ (libapreq-2.X.X ???)
> perl/ (stuff that should be in mod_perl-2)
It'll be in mod_perl-2.0 *only* if apreq becomes a part of the core,
which I'm afraid won't happen. You can't do much if you aren't one of
them, so I've tried to "bribe" a few of them but in vain and I think
it's the best to forget about this option, move the project on as a
standalone one and provide the perl glue internally just like 1.0 did.
The building code can be rewritten to find httpd-2.0 and build after
httpd-2.0 has been built and optionally installed. It's definitely a bad
idea to keep apreq-2.0 as a patch to httpd-2.0 any longer.
> tcl/ (...)
> php/
> python/
> java/
+1 on the layout. An alternative layout could be:
core/
glue/
perl
php
...
because /c/ is really a core. and putting all languages extensions in
one dir will make it easy to 'make all' to build all extensions... just
an idea.
> The apreq-2 directory shouldn't have a Makefile.PL
> to worry about, and I don't plan to put anything
> into any of the "language" directories right now;
> just in httpd/.
But there is a problem with not doing that. If you distribute the
package on CPAN you need Makefile.PL to be in the top tree.
>>Also would be nice to have the name consistent with httpd-2.0,
>>modperl-2.0... => apreq-2.0.
>
>
> We'll certainly do that at the right time. I don't think
> we're there yet, though. IMO, the level of core support
> we can rely on for 2.x, needs to be *explicit* before then.
>
> Based on dev@'s recent history regarding code contributions,
> I see no reason to expect them to accomodate us. "Good faith"
> isn't a word I would attach to their decision regarding
> Jon Travis' HTML parser.
>
> http://marc.theaimsgroup.com/?t=103177775400001&r=1&w=2
>
> Alternatively, I could put cvs repository inside my apache
> home directory, but I don't know how to make that available
> through anoncvs. Is that a possibility?
We all agree that waiting for httpd people to give a grace is a complete
waste of time. I suggest that we ask Brian Behlendorf to create the
apreq-2.0 repository and start working there. It's important for
preserving the history of changes. I see no reason why not to do it
*now*. Having a repository doesn't mean having a production version of
the code.
__________________________________________________________________
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
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> [...]
> > Instead of making another repository on cvs.apache.org,
> > I'm going to create an apreq-2/ directory within our current
> > cvs, and then start dumping stuff into apreq-2/.
>
> That's probabably a bad idea, at least for a reason that if you have
> Makefile.PL in apreq-2 (later) the root dir's Makefile.PL will process
> the sub-dir's one as well.
Problem noted- thanks for pointing it out.
> I don't see any reason why not to create a whole new rep, like all
> other projects do. Unless you plan to have this one only temporary
> till the destiny of apreq2 is cleared up.
That's my plan: to make apreq-2/ (for now) a *temporary*
location for apreq-2 development. The directory structure I
have in mind looks something like this:
apreq-2/
httpd/ (server support for apreq-2)
c/ (libapreq-2.X.X ???)
perl/ (stuff that should be in mod_perl-2)
tcl/ (...)
php/
python/
java/
The apreq-2 directory shouldn't have a Makefile.PL
to worry about, and I don't plan to put anything
into any of the "language" directories right now;
just in httpd/.
> Also would be nice to have the name consistent with httpd-2.0,
> modperl-2.0... => apreq-2.0.
We'll certainly do that at the right time. I don't think
we're there yet, though. IMO, the level of core support
we can rely on for 2.x, needs to be *explicit* before then.
Based on dev@'s recent history regarding code contributions,
I see no reason to expect them to accomodate us. "Good faith"
isn't a word I would attach to their decision regarding
Jon Travis' HTML parser.
http://marc.theaimsgroup.com/?t=103177775400001&r=1&w=2
Alternatively, I could put cvs repository inside my apache
home directory, but I don't know how to make that available
through anoncvs. Is that a possibility?
--
Joe Schaefer
Re: cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
[...]
> Instead of making another repository on cvs.apache.org,
> I'm going to create an apreq-2/ directory within our current
> cvs, and then start dumping stuff into apreq-2/.
That's probabably a bad idea, at least for a reason that if you have
Makefile.PL in apreq-2 (later) the root dir's Makefile.PL will process
the sub-dir's one as well.
I don't see any reason why not to create a whole new rep, like all other
projects do. Unless you plan to have this one only temporary till the
destiny of apreq2 is cleared up.
Also would be nice to have the name consistent with httpd-2.0,
modperl-2.0... => apreq-2.0.
__________________________________________________________________
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
cvs tagged as v1_1 (was Re: 1.1_rc4)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
I just tagged cvs as v1_1; as far as I'm concerned 1.1 is
fait accompli. I've updated my apache webpage accordingly;
the rest is up to Jim.
Instead of making another repository on cvs.apache.org,
I'm going to create an apreq-2/ directory within our current
cvs, and then start dumping stuff into apreq-2/. In the near
term, whatever temporary patches we need for httpd-2.0 (and
httpd-test) can just go into the existing patches/ directory.
Hopefully such patches won't be needed for *too* long.
--
Joe Schaefer
Re: 1.1_rc4
Posted by David Wheeler <da...@wheeler.net>.
On Thursday, January 9, 2003, at 02:23 PM, Joe Schaefer wrote:
>>> Builds fine and passes all tests on Win32 ...
>>
>> On Mac OS X 10.2, too.
>
> Great! Looks like we just need Jim to work his magic now.
Yeah, it's still not specifically tested on Mac OS X 10.1, but the
patch had worked for me there before, and fewer and fewer people will
be running 10.1 going forward, anyway. Ken was one of the last holdouts.
> Looks like somebody beat you to it on January 5 :-)
D'oh! That's what I get for not doing a cvs update, first!
Later,
David
--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Re: 1.1_rc4
Posted by Joe Schaefer <jo...@sunstarsys.com>.
David Wheeler <da...@wheeler.net> writes:
> On Wednesday, January 8, 2003, at 08:55 PM, Randy Kobes wrote:
[...]
> > Builds fine and passes all tests on Win32 ...
>
> On Mac OS X 10.2, too.
Great! Looks like we just need Jim to work his magic now.
> However, since it's now unpacking into libapreq-1.1 instead of
> httpd-apreq-1.1, I submit the attached patch for INSTALL.MacOSX.
Looks like somebody beat you to it on January 5 :-)
To get the most up-to-date diff against cvs, type
% cvs update
% cvs diff
The rc4 version of INSTALL.MacOSX should cover the items
in your patch.
--
Joe Schaefer
Re: 1.1_rc4
Posted by David Wheeler <da...@wheeler.net>.
On Wednesday, January 8, 2003, at 08:55 PM, Randy Kobes wrote:
> On 8 Jan 2003, Joe Schaefer wrote:
>
>> The current cvs is rc4; please test that
>> it's OK:
>>
>> http://www.apache.org/~joes/libapreq-1.1_rc4.tar.gz
>>
>> Assuming Sven Geisler OK's it, I'm +1
>> for releasing it as 1.1.
>
> Builds fine and passes all tests on Win32 ...
On Mac OS X 10.2, too. However, since it's now unpacking into
libapreq-1.1 instead of httpd-apreq-1.1, I submit the attached patch
for INSTALL.MacOSX.
Regards,
David
--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Re: 1.1_rc4
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On 8 Jan 2003, Joe Schaefer wrote:
> The current cvs is rc4; please test that
> it's OK:
>
> http://www.apache.org/~joes/libapreq-1.1_rc4.tar.gz
>
> Assuming Sven Geisler OK's it, I'm +1
> for releasing it as 1.1.
Builds fine and passes all tests on Win32 ...
--
best regards,
randy