You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Philip M. Gollucci" <pg...@p6m7g8.com> on 2006/10/29 09:49:25 UTC
[RELEASE CANDIDATES] Status ?
Hi all, so it seems I dropped the ball on the releases. I'm about to get back into it.
Does anyone know of any issues that are still oustanding from
mod_perl-2.0.3-RC1
Apache-Test 1.29-RC1
libapreq2 2.09-RC1
before I roll -RC2s. I'm pretty sure Apache-Test and libapreq2 will be ready with -RC2
for release. mod_perl might need a -RC3.
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
When I call your name, Girl, it starts to flame
Burning in my heart, Tearing it all apart..
No matter how I try My love I cannot hide....
Re: [RELEASE CANDIDATES] Status ?
Posted by Fred Moyer <fr...@taperfriendlymusic.org>.
Philip M. Gollucci wrote:
> Hi all, so it seems I dropped the ball on the releases. I'm about to
> get back into it.
>
> Does anyone know of any issues that are still oustanding from
> mod_perl-2.0.3-RC1
> Apache-Test 1.29-RC1
> libapreq2 2.09-RC1
>
> before I roll -RC2s. I'm pretty sure Apache-Test and libapreq2 will be
> ready with -RC2
> for release. mod_perl might need a -RC3.
There's one issue I know of with libapreq2 (thread on it earlier today),
but I have had one of those bad computer weeks and haven't had enough
time to put together a decent report for the list. I'll try to get
something to you early this week on it, hopefully with a reproducible
test case.
Re: [RELEASE CANDIDATES] Status ?
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Philip M. Gollucci wrote:
> Hi all, so it seems I dropped the ball on the releases. I'm about to
> get back into it.
>
> Does anyone know of any issues that are still oustanding from
> mod_perl-2.0.3-RC1
> Apache-Test 1.29-RC1
> libapreq2 2.09-RC1
>
> before I roll -RC2s. I'm pretty sure Apache-Test and libapreq2 will be
> ready with -RC2
> for release. mod_perl might need a -RC3.
So Fred's issues was foo-bar and I've just committed Nikolay's patch.
If I hear nothing else, I'll roll -RC2s Thursday night.
Nobody better be working tonight :)
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
When I call your name, Girl, it starts to flame
Burning in my heart, Tearing it all apart..
No matter how I try My love I cannot hide....
Re: [RELEASE CANDIDATES] Status ?
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Philip M. Gollucci wrote:
> Hi all, so it seems I dropped the ball on the releases. I'm about to
> get back into it.
>
> Does anyone know of any issues that are still oustanding from
> mod_perl-2.0.3-RC1
> Apache-Test 1.29-RC1
> libapreq2 2.09-RC1
>
> before I roll -RC2s. I'm pretty sure Apache-Test and libapreq2 will be
> ready with -RC2
> for release. mod_perl might need a -RC3.
So Fred's issues was foo-bar and I've just committed Nikolay's patch.
If I hear nothing else, I'll roll -RC2s Thursday night.
Nobody better be working tonight :)
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
When I call your name, Girl, it starts to flame
Burning in my heart, Tearing it all apart..
No matter how I try My love I cannot hide....
Re: [RELEASE CANDIDATES] Status ?
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Philip M. Gollucci wrote:
> Hi all, so it seems I dropped the ball on the releases. I'm about to
> get back into it.
>
> Does anyone know of any issues that are still oustanding from
> mod_perl-2.0.3-RC1
> Apache-Test 1.29-RC1
> libapreq2 2.09-RC1
>
> before I roll -RC2s. I'm pretty sure Apache-Test and libapreq2 will be
> ready with -RC2
> for release. mod_perl might need a -RC3.
So Fred's issues was foo-bar and I've just committed Nikolay's patch.
If I hear nothing else, I'll roll -RC2s Thursday night.
Nobody better be working tonight :)
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
When I call your name, Girl, it starts to flame
Burning in my heart, Tearing it all apart..
No matter how I try My love I cannot hide....
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [RELEASE CANDIDATES] Status ?
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Philip M. Gollucci wrote:
> Hi all, so it seems I dropped the ball on the releases. I'm about to
> get back into it.
>
> Does anyone know of any issues that are still oustanding from
> mod_perl-2.0.3-RC1
> Apache-Test 1.29-RC1
> libapreq2 2.09-RC1
>
> before I roll -RC2s. I'm pretty sure Apache-Test and libapreq2 will be
> ready with -RC2
> for release. mod_perl might need a -RC3.
So Fred's issues was foo-bar and I've just committed Nikolay's patch.
If I hear nothing else, I'll roll -RC2s Thursday night.
Nobody better be working tonight :)
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
When I call your name, Girl, it starts to flame
Burning in my heart, Tearing it all apart..
No matter how I try My love I cannot hide....
Re: [RELEASE CANDIDATES] Status ?
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:
> Why not just use GATEWAY_INTERFACE? That way we don't need to argue
> about the actual adoption of RFC 3875 (not a standard) vs the original
> (ambiguous) CGI spec.
Actually I took a peek around, and I think both IIS and Tomcat support
3875. So as long as it's documented, I don't mind if we rely on this
spec as well.
--
Joe Schaefer
Re: [RELEASE CANDIDATES] Status ?
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Issac Goldstand <ma...@beamartyr.net> writes:
> That's what I originally thought when told to do it this way, but its wrong.
> RFC 3875 section 4.1.7 says
>
> The server MUST set this variable; if the Script-URI does not include
> a query component, the QUERY_STRING MUST be defined as an empty
> string ("").
>
> So it does need to be there, and therefore apreq_handle_cgi() won't
> change the behavior *as long as* the CGI provider is RFC-compliant
Why not just use GATEWAY_INTERFACE? That way we don't need to argue
about the actual adoption of RFC 3875 (not a standard) vs the original
(ambiguous) CGI spec.
>> (you can't assume the webserver is
>> apache), and the docs for apreq_handle_cgi() currently suck:
>>
>> "Create an apreq handle which is suitable for a CGI program. It reads
>> input from stdin and writes output to stdout."
>>
>>
>> >From the documentation, I have no idea what that the specified behavior is
>> supposed to be, other than to say the symbol should
>> "work" in any CGI environment. (Not sure even why it claims to write
>> anything to stdout, since we don't bake() cookies anymore).
>>
> Right. Are those docs generated by anything other than doxygen-ing
> the source?
> Maybe I can get some time (and find the patience) to try to spice them up a
> bit...
Yeah, it's all doxygen-generated. The symbol is in apreq_module.h I think.
>> As a user, when I see lame documentation like that for a symbol in a
>> released library, I assume the devs haven't gotten around to docmenting the
>> current behavior- not that they haven't yet decided what the behavior
>> should be.
>>
>> So, IMO the branch has a long way to go before it's suitable for merging
>> into trunk. At a minimum it needs documentation and tests for the new
>> behavior. You also need to decide if this stuff is a 2.x feature, in
>> which case a new module (could bundle with libapreq alongside cgi) might
>> be more appropriate. Or is it a 3.0 feature, in which case changing the
>> behavior of apreq_handle_cgi() is ok
> In my original post[1], I mentioned that I personally think a separate module
> (enhanced_cgi?) might be smarter, but I got no response, so continued
> development the way my boss wanted to have it done in-house, and
> figured we can always split later.
It's your call whether you want to do a new module, writing all the
tests, docs and perl glue, or work with the existing cgi module. I
think it's possible to work with the existing cgi module and incorporate
the changes into the 2.x line, but it'd require *serious* documention
work. You'd have to explain how people could get the old behavior back
if they wanted it, (eg. by including the GATEWAY_INTERFACE env var for
instance).
--
Joe Schaefer
Re: [RELEASE CANDIDATES] Status ?
Posted by Issac Goldstand <ma...@beamartyr.net>.
Joe Schaefer wrote:
> Issac Goldstand <ma...@beamartyr.net> writes:
>
>
>> Philip M. Gollucci wrote:
>>
>
> [...]
>
>
>>> Sadly, I don't think this can go into the 2.x series because of our
>>> conversioning rules.
>>> New features need new symbols. SVN gets around this by doing:
>>> void foo (void)
>>> void foo2 (int)
>>>
>> Can you elaborate? I didn't understand that bit.
>>
>
> The branch changes the behavior of apreq_handle_cgi(). The CGI specs
> make no guarantee about the existence of a QUERY_STRING env var when
> the url doesn't contain a "?"
That's what I originally thought when told to do it this way, but its
wrong. RFC 3875 section 4.1.7 says
The server MUST set this variable; if the Script-URI does not include
a query component, the QUERY_STRING MUST be defined as an empty
string ("").
So it does need to be there, and therefore apreq_handle_cgi() won't
change the behavior *as long as* the CGI provider is RFC-compliant
> (you can't assume the webserver is
> apache), and the docs for apreq_handle_cgi() currently suck:
>
>
> "Create an apreq handle which is suitable for a CGI program. It reads
> input from stdin and writes output to stdout."
>
>
> >From the documentation, I have no idea what that the specified
> behavior is supposed to be, other than to say the symbol should
> "work" in any CGI environment. (Not sure even why it claims to
> write anything to stdout, since we don't bake() cookies anymore).
>
Right. Are those docs generated by anything other than doxygen-ing the
source? Maybe I can get some time (and find the patience) to try to
spice them up a bit...
> As a user, when I see lame documentation like that for a symbol in a
> released library, I assume the devs haven't gotten around to docmenting the
> current behavior- not that they haven't yet decided what the behavior
> should be.
>
> So, IMO the branch has a long way to go before it's suitable for merging
> into trunk. At a minimum it needs documentation and tests for the new
> behavior. You also need to decide if this stuff is a 2.x feature, in
> which case a new module (could bundle with libapreq alongside cgi) might
> be more appropriate. Or is it a 3.0 feature, in which case changing the
> behavior of apreq_handle_cgi() is ok
In my original post[1], I mentioned that I personally think a separate
module (enhanced_cgi?) might be smarter, but I got no response, so
continued development the way my boss wanted to have it done in-house,
and figured we can always split later.
Regarding tests for this, now that the subject seems to have attracted
some interest, does anyone have any suggestions on how to best test
this? Since the point is to communicate interactively via STDIN/STDOUT,
I'm not sure how to best test it (beyond making sure that the existing
CGI tests don't break - they currently don't)
Issac
[1] http://marc.theaimsgroup.com/?l=apreq-dev&m=116004301004962&w=2
Re: [RELEASE CANDIDATES] Status ?
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Issac Goldstand <ma...@beamartyr.net> writes:
> Philip M. Gollucci wrote:
[...]
>> Sadly, I don't think this can go into the 2.x series because of our
>> conversioning rules.
>> New features need new symbols. SVN gets around this by doing:
>> void foo (void)
>> void foo2 (int)
> Can you elaborate? I didn't understand that bit.
The branch changes the behavior of apreq_handle_cgi(). The CGI specs
make no guarantee about the existence of a QUERY_STRING env var when
the url doesn't contain a "?" (you can't assume the webserver is
apache), and the docs for apreq_handle_cgi() currently suck:
"Create an apreq handle which is suitable for a CGI program. It reads
input from stdin and writes output to stdout."
>From the documentation, I have no idea what that the specified
behavior is supposed to be, other than to say the symbol should
"work" in any CGI environment. (Not sure even why it claims to
write anything to stdout, since we don't bake() cookies anymore).
As a user, when I see lame documentation like that for a symbol in a
released library, I assume the devs haven't gotten around to docmenting the
current behavior- not that they haven't yet decided what the behavior
should be.
So, IMO the branch has a long way to go before it's suitable for merging
into trunk. At a minimum it needs documentation and tests for the new
behavior. You also need to decide if this stuff is a 2.x feature, in
which case a new module (could bundle with libapreq alongside cgi) might
be more appropriate. Or is it a 3.0 feature, in which case changing the
behavior of apreq_handle_cgi() is ok?
--
Joe Schaefer
Re: [RELEASE CANDIDATES] Status ?
Posted by Issac Goldstand <ma...@beamartyr.net>.
Philip M. Gollucci wrote:
> this one time in band camp Issac Goldstand said on 10/29/06 01:41:
>> If you're planning on rolling libapreq-2.09 soon, maybe we should
>> include the intial work done in /branches/enhanced-cgi/
>> <http://svn.apache.org/repos/asf/httpd/apreq/branches/enhanced-cgi/>
>> It seems stable at the moment.
> Hi, yes, it looks interesting, but please keep replies on list.
Sorry. Hit reply instead of reply-all...
>
> Also, you need to update the
> include/apreq_version.h
> *_VERSION #defines.
> [You should do this on _EVERY_ commit]
>
Gotcha. Thanks. I guess this is what comes of work tearing me away
from apreq a couple of weeks after getting voted in as a committer :-/
Hopefully, I'll be able to remedy that now that I'm working on
Apache-based projects again.
> Sadly, I don't think this can go into the 2.x series because of our
> conversioning rules.
> New features need new symbols. SVN gets around this by doing:
> void foo (void)
> void foo2 (int)
Can you elaborate? I didn't understand that bit.
Issac
Re: [RELEASE CANDIDATES] Status ?
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
this one time in band camp Issac Goldstand said on 10/29/06 01:41:
> If you're planning on rolling libapreq-2.09 soon, maybe we should
> include the intial work done in /branches/enhanced-cgi/
> <http://svn.apache.org/repos/asf/httpd/apreq/branches/enhanced-cgi/>
> It seems stable at the moment.
Hi, yes, it looks interesting, but please keep replies on list.
Also, you need to update the
include/apreq_version.h
*_VERSION #defines.
[You should do this on _EVERY_ commit]
Sadly, I don't think this can go into the 2.x series because of our conversioning rules.
New features need new symbols. SVN gets around this by doing:
void foo (void)
void foo2 (int)
I don't know if we wan to go that route, its just one possible path.
>
> Issac
>
> Philip M. Gollucci wrote:
>> Hi all, so it seems I dropped the ball on the releases. I'm about to
>> get back into it.
>>
>> Does anyone know of any issues that are still oustanding from
>> mod_perl-2.0.3-RC1
>> Apache-Test 1.29-RC1
>> libapreq2 2.09-RC1
>>
>> before I roll -RC2s. I'm pretty sure Apache-Test and libapreq2 will
>> be ready with -RC2
>> for release. mod_perl might need a -RC3.
>>
>>
>> ------------------------------------------------------------------------
>> Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
>> Consultant / http://p6m7g8.net/Resume/resume.shtml
>> Senior Software Engineer - TicketMaster - http://ticketmaster.com
>> 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
>>
>> When I call your name, Girl, it starts to flame
>> Burning in my heart, Tearing it all apart..
>> No matter how I try My love I cannot hide....
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
When I call your name, Girl, it starts to flame
Burning in my heart, Tearing it all apart..
No matter how I try My love I cannot hide....