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/04/25 18:39:18 UTC
Updating the Website?
I have no clue how to get my commits to httpd-site
to show up at http://httpd.apache.org/apreq.
If anyone figures out how to update the website,
please post that information to this list so
we have it for future reference.
Thanks.
--
Joe Schaefer
Re: [rfc] a few milestones (was Re: Updating the Website?)
Posted by Stas Bekman <st...@stason.org>.
Issac Goldstand wrote:
> My $0.02:
> I think we're making too many new root namespaces for modperl2: Apache2::
> APR:: ModPerl:: etc
> I think that we should start taking one of those as a "roof" as to not
> create too much confusing clutter; after all, ALL of these namespaces are
> logically connected because they ALL require mod_perl2, so IMHO they should
> be grouped together, not spread all around CPAN. Plus, think about
> third-party developers. They're gonna go bananas trying to figure out which
> of these new namespaces to start developing for. So I'm against making
> either an Apreq:: or an APREQ:: suite. I think we sould either use
> Apahe2::Request , Cookie, etc (or transparent Apache:: mp1 and mp2 aware
> modules) or Apache2 (or whatever root namesspace) ::Apreq::...
First of all, APR:: is different as it doesn't require mod_perl.
Second, I have tried to have this discussion long time ago on the modperl dev
list, with very little interest from other 3rd party module developers.
Perhaps you want to review the relevant threads, at least these ones:
http://marc.theaimsgroup.com/?t=103819276700005&r=1&w=2
http://marc.theaimsgroup.com/?t=99075989400003&r=1&w=2
But I remember there were several other similar discussions.
Currently in 2.0 we have Apache:: and ModPerl:: namespaces, with Apache:: for
Apache specific modules and ModPerl:: for mod_perl specific modules.
FWIW, Apache::Request and Apache::Cookie are still available for mp2. Based on
the above threads appending the suffix '2' wasn't a favorable solution.
In any case, if you discuss the non-specific to apreq things, it's better to
do on the list where other 3rd party module developers may chime in.
__________________________________________________________________
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: [rfc] a few milestones (was Re: Updating the Website?)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
"Issac Goldstand" <ma...@beamartyr.net> writes:
> My $0.02:
> I think we're making too many new root namespaces for modperl2:
> Apache2:: APR:: ModPerl:: etc
> I think that we should start taking one of those as a "roof" as to
> not create too much confusing clutter; after all, ALL of these
> namespaces are logically connected because they ALL require mod_perl2,
Fair enough, but there's lots of new things in libapreq that
we should clarify:
1) libapreq-2 no longer requires httpd to operate; it can be
used in other environments (like CGI) now. IMO it would
be nice if CGI scripts that use our Perl API (whatever
it turns out to be) will also work cleanly as Apache::Registry
scripts.
2) libapreq-2 is meant to be safe to use just about anywhere
within the server: hooks, filters, handlers, etc. The
downside is that it's no longer possible for libapreq to
automatically do the POST parsing (we've relinquished
control of that to the content-handler itself).
> Plus, think about third-party developers. They're gonna go bananas
> trying to figure out which of these new namespaces to start developing
> for. So I'm against making either an Apreq:: or an APREQ:: suite.
What concerns me most about Apache::Request is backwards-compatibility.
If people prefer to document the changes to Apache::Request instead
of introducing a new namespace, that's fine with me also.
--
Joe Schaefer
Re: [rfc] a few milestones (was Re: Updating the Website?)
Posted by Stas Bekman <st...@stason.org>.
Issac Goldstand wrote:
>>There is no reason not to have the Apache2 namespace provide the entry
>>points that Apache13 modperl porters need. Apache::compat already helps
>>a lot with that. But do keep these various modules separate, and if you
>
> want
>
>>to clean up CPAN, I'd suggest we adopt three level namespaces, with the
>>top level Apache:: (not httpd server, but the software foundation), or
>
> simply
>
>>ASF:: designator.
>>
>
>
> Actually, the 3 level idea is *exactly* what I had in mind...
Been there, tried to suggest that already, those developers who participated
in the discussion didn't like that idea. Again please check the modperl-dev
archives.
__________________________________________________________________
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: [rfc] a few milestones (was Re: Updating the Website?)
Posted by Issac Goldstand <ma...@beamartyr.net>.
> There is no reason not to have the Apache2 namespace provide the entry
> points that Apache13 modperl porters need. Apache::compat already helps
> a lot with that. But do keep these various modules separate, and if you
want
> to clean up CPAN, I'd suggest we adopt three level namespaces, with the
> top level Apache:: (not httpd server, but the software foundation), or
simply
> ASF:: designator.
>
Actually, the 3 level idea is *exactly* what I had in mind...
Issac
Re: [rfc] a few milestones (was Re: Updating the Website?)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 02:52 AM 4/28/2003, Issac Goldstand wrote:
>My $0.02:
> I think we're making too many new root namespaces for modperl2: Apache2::
>APR:: ModPerl:: etc
>I think that we should start taking one of those as a "roof" as to not
>create too much confusing clutter; after all, ALL of these namespaces are
>logically connected because they ALL require mod_perl2, so IMHO they should
>be grouped together, not spread all around CPAN.
Well, yes and no. They are all part of the asf (just as Jakartaland defines
multi-depth namespaces with Apache at the top of that namespace.)
But Apache web server isn't Apache2, APR is a distinct package, and we
have two separate packages, modperl and modperl2. You presume they
all plug into a Apache(n) modperl(n) web server, but it ain't necessarily so.
I suppose it would be nice if the perlland coders wanted to adopt three level
namespaces so we all end up under an Apache umbrella. But all these
packages don't belong dumped into the same top level namespace of our
traditional two level depth.
>Plus, think about third-party developers. They're gonna go bananas trying
>to figure out which of these new namespaces to start developing for.
Sure, is pool->create in APR, or Apache13? Hmmm... mp1 module, so that
must be in Apache13! Or must it?
Actually, several modules already use APR with Apache13. This is actually
a "good thing"(R) that we support already, becuase APR is seperate from
Apache and Apache2.
What I'm asking is that you don't assume it all falls together as you expect.
You will surprise yourself and your users what can be done mixing some
different modules. Also consider that a single perl install aught to be able
to have mp/mp2 and Apache13/Apache2 plus APR all coexisting together.
That something that doesn't even work today, I don't believe... but it would
be a nice goal.
There is no reason not to have the Apache2 namespace provide the entry
points that Apache13 modperl porters need. Apache::compat already helps
a lot with that. But do keep these various modules separate, and if you want
to clean up CPAN, I'd suggest we adopt three level namespaces, with the
top level Apache:: (not httpd server, but the software foundation), or simply
ASF:: designator.
Bill
Re: [rfc] a few milestones (was Re: Updating the Website?)
Posted by Issac Goldstand <ma...@beamartyr.net>.
My $0.02:
I think we're making too many new root namespaces for modperl2: Apache2::
APR:: ModPerl:: etc
I think that we should start taking one of those as a "roof" as to not
create too much confusing clutter; after all, ALL of these namespaces are
logically connected because they ALL require mod_perl2, so IMHO they should
be grouped together, not spread all around CPAN. Plus, think about
third-party developers. They're gonna go bananas trying to figure out which
of these new namespaces to start developing for. So I'm against making
either an Apreq:: or an APREQ:: suite. I think we sould either use
Apahe2::Request , Cookie, etc (or transparent Apache:: mp1 and mp2 aware
modules) or Apache2 (or whatever root namesspace) ::Apreq::...
Issac
----- Original Message -----
From: "Stas Bekman" <st...@stason.org>
To: "Joe Schaefer" <jo...@sunstarsys.com>
Cc: "apreq dev list" <ap...@httpd.apache.org>
Sent: Monday, April 28, 2003 2:18 AM
Subject: Re: [rfc] a few milestones (was Re: Updating the Website?)
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
> >
> > [...]
> >
> >
> >>Won't the same approach as used in apreq-1.x work?
> >
> >
> > I don't think so. IMO libapreq-2 (the core) should have only
> > one build system per platform, not two systems (perl & configure)
> > like apreq-1 has.
>
> Agreed.
>
> >>I also don't quite get why do we need c-modules for the perl glue
testing.
> >
> >
^^^^^^^^^^^^
> >
> > We don't need c-modules for that. We need c-modules to test the
> > code in env/, since the unit tests in t/ can't do that. It just
> > seems convenient to put those environment tests in glue/perl since
> > they require Apache::Test.
>
> Still, we better separate these, folks that don't need mod_perl shouldn't
have
> a requirement to build it just to run tests. We can have two test suits.
>
> >>I don't remember when we have discussed this, but won't ApReq:: read
> >>better?
> >
> > Not if it means we keep changing the preferred capitalization every
> > few months :-). Me no like StudlyCaps for perl modules, so I'm -0
> > on ApReq.
>
> We don't have any perl modules yet, so it's not like we have this problem
yet.
> It's not about capitalization, but ambiguity. APREQ:: to me means an
> abbreviation of A.P.R.E.Q which is not the case. (e.g. APR::)
>
> Apreq is fine with me too.
>
> __________________________________________________________________
> 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: [rfc] a few milestones (was Re: Updating the Website?)
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>Won't the same approach as used in apreq-1.x work?
>
>
> I don't think so. IMO libapreq-2 (the core) should have only
> one build system per platform, not two systems (perl & configure)
> like apreq-1 has.
Agreed.
>>I also don't quite get why do we need c-modules for the perl glue testing.
>
> ^^^^^^^^^^^^
>
> We don't need c-modules for that. We need c-modules to test the
> code in env/, since the unit tests in t/ can't do that. It just
> seems convenient to put those environment tests in glue/perl since
> they require Apache::Test.
Still, we better separate these, folks that don't need mod_perl shouldn't have
a requirement to build it just to run tests. We can have two test suits.
>>I don't remember when we have discussed this, but won't ApReq:: read
>>better?
>
> Not if it means we keep changing the preferred capitalization every
> few months :-). Me no like StudlyCaps for perl modules, so I'm -0
> on ApReq.
We don't have any perl modules yet, so it's not like we have this problem yet.
It's not about capitalization, but ambiguity. APREQ:: to me means an
abbreviation of A.P.R.E.Q which is not the case. (e.g. APR::)
Apreq is fine with me too.
__________________________________________________________________
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: [rfc] a few milestones (was Re: Updating the Website?)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> Won't the same approach as used in apreq-1.x work?
I don't think so. IMO libapreq-2 (the core) should have only
one build system per platform, not two systems (perl & configure)
like apreq-1 has.
> It doesn't require 'make install' to build/test the perl glue.
Right, and it shouldn't with apreq-2 either. Hopefully someone
will fix that.
> I also don't quite get why do we need c-modules for the perl glue testing.
^^^^^^^^^^^^
We don't need c-modules for that. We need c-modules to test the
code in env/, since the unit tests in t/ can't do that. It just
seems convenient to put those environment tests in glue/perl since
they require Apache::Test.
[...]
> I don't remember when we have discussed this, but won't ApReq:: read
> better?
Not if it means we keep changing the preferred capitalization every
few months :-). Me no like StudlyCaps for perl modules, so I'm -0
on ApReq.
--
Joe Schaefer
Re: [rfc] a few milestones (was Re: Updating the Website?)
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
>>>The next one is within easy reach:
>>> 2) a basic test framework
>>> a) simple unit tests for libapreq.so (the core).
>>> b) simple Apache::Test tests for mod_apreq.
>>>2a is already done (in t/), while 2b needs more work. I already laid the
>>>foundation for 2b in glue/perl/.
>>>Perhaps some of us perl guys can finish that part off while working towards
>>
>>Are you talking about applying the XP principles: write tests before
>>you code? If not won't 3 be a prerequisite for 2b?
>
>
> Personally I think writing tests ASAP is a good idea,
> but I'm not dogmatic about it. What I really mean is
> something a bit more pragmatic: right now there's a c-module
> test in glue/perl that runs perfectly on my box. However,
> to get it to run I have to do all this:
>
> % cd httpd-apreq-2
> % ./buildconf && configure --enable-maintainer-mode --with-apache2-apxs=...
> % make && make test
> % make install
> % cd glue/perl
> % perl Makefile.PL -apxs ...
> % make test
>
> At the very least, I'd like to avoid having to install
> mod_apreq && libapreq.so prior to running the Apache::Test
> test in glue/perl.
Won't the same approach as used in apreq-1.x work? It doesn't require 'make
install' to build/test the perl glue.
I also don't quite get why do we need c-modules for the perl glue testing.
>>> 3) Functional APREQ:: packages (perl glue for libapreq).
>>
>>It all depends on how rich is the API that we expose to Perl.
>>If it's quite rick we probably better go with:
>>http://search.cpan.org/author/GRICHTER/ExtUtils-XSBuilder-0.23/
>>which is a generalized port of mod_perl 2.0's WrapXS.
>
>
> I've been looking over the modperl XS code recently, and
> the WrapXS stuff looks really neat. In any case we'll need
> to reuse some of the APR typemaps from modperl-2 in order to
> wrap libapreq.
That typemap is installed systems wide, so it's be automatically included by
ModPerl::MM, which is a replacement for Apache::src.
>>> 4) Apache::Request / Apache::Cookie ports using
>>> the APREQ:: modules.
>>
>>I suppose that 3 should be completed first, before 4 can be done.
>
>
> Yeah, but I think 3 + 4 will pretty much happen simultaneously.
> The hard part will be getting the .xs files working, and
> I'm expecting those to all be APREQ:: packages. Apache::Request
> and Apache::Cookie will probably turn out to just be (tiny) .pm
> files.
I don't remember when we have discussed this, but won't ApReq:: read better?
__________________________________________________________________
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: [rfc] a few milestones (was Re: Updating the Website?)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
[...]
> > The next one is within easy reach:
> > 2) a basic test framework
> > a) simple unit tests for libapreq.so (the core).
> > b) simple Apache::Test tests for mod_apreq.
> > 2a is already done (in t/), while 2b needs more work. I already laid the
> > foundation for 2b in glue/perl/.
> > Perhaps some of us perl guys can finish that part off while working towards
>
> Are you talking about applying the XP principles: write tests before
> you code? If not won't 3 be a prerequisite for 2b?
Personally I think writing tests ASAP is a good idea,
but I'm not dogmatic about it. What I really mean is
something a bit more pragmatic: right now there's a c-module
test in glue/perl that runs perfectly on my box. However,
to get it to run I have to do all this:
% cd httpd-apreq-2
% ./buildconf && configure --enable-maintainer-mode --with-apache2-apxs=...
% make && make test
% make install
% cd glue/perl
% perl Makefile.PL -apxs ...
% make test
At the very least, I'd like to avoid having to install
mod_apreq && libapreq.so prior to running the Apache::Test
test in glue/perl.
> > 3) Functional APREQ:: packages (perl glue for libapreq).
>
> It all depends on how rich is the API that we expose to Perl.
> If it's quite rick we probably better go with:
> http://search.cpan.org/author/GRICHTER/ExtUtils-XSBuilder-0.23/
> which is a generalized port of mod_perl 2.0's WrapXS.
I've been looking over the modperl XS code recently, and
the WrapXS stuff looks really neat. In any case we'll need
to reuse some of the APR typemaps from modperl-2 in order to
wrap libapreq.
[...]
> > 4) Apache::Request / Apache::Cookie ports using
> > the APREQ:: modules.
>
> I suppose that 3 should be completed first, before 4 can be done.
Yeah, but I think 3 + 4 will pretty much happen simultaneously.
The hard part will be getting the .xs files working, and
I'm expecting those to all be APREQ:: packages. Apache::Request
and Apache::Cookie will probably turn out to just be (tiny) .pm
files.
--
Joe Schaefer
Re: [rfc] a few milestones (was Re: Updating the Website?)
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
>
>>I have no clue how to get my commits to httpd-site
>>to show up at http://httpd.apache.org/apreq.
>>If anyone figures out how to update the website,
>>please post that information to this list so
>>we have it for future reference.
>
>
> Open mouth, insert foot. Looks like the changes finally
> took, but I'm still not sure what actually caused that
> to happen.
>
> I'm not planning to make any substantial changes to the
> apreq-2 core for a week or so, so please give some thought
> to the open issues listed in the STATUS file. Maybe
> we should also lay out a roadmap of milestones for apreq-2?
> Personally I believe we've surpassed at least one so far:
>
> 1) an operational core based solely on APR, with
> a functional Apache2 environment.
joe++
> The next one is within easy reach:
>
> 2) a basic test framework
> a) simple unit tests for libapreq.so (the core).
> b) simple Apache::Test tests for mod_apreq.
>
> 2a is already done (in t/), while 2b needs more work.
> I already laid the foundation for 2b in glue/perl/.
> Perhaps some of us perl guys can finish that part
> off while working towards
Are you talking about applying the XP principles: write tests before you code?
If not won't 3 be a prerequisite for 2b?
> 3) Functional APREQ:: packages (perl glue for libapreq).
It all depends on how rich is the API that we expose to Perl.
If it's quite rick we probably better go with:
http://search.cpan.org/author/GRICHTER/ExtUtils-XSBuilder-0.23/
which is a generalized port of mod_perl 2.0's WrapXS.
Otherwise, if the API is not very big, a hand coded XS will probably do.
> 4) Apache::Request / Apache::Cookie ports using
> the APREQ:: modules.
I suppose that 3 should be completed first, before 4 can be done.
__________________________________________________________________
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
[rfc] a few milestones (was Re: Updating the Website?)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:
> I have no clue how to get my commits to httpd-site
> to show up at http://httpd.apache.org/apreq.
> If anyone figures out how to update the website,
> please post that information to this list so
> we have it for future reference.
Open mouth, insert foot. Looks like the changes finally
took, but I'm still not sure what actually caused that
to happen.
I'm not planning to make any substantial changes to the
apreq-2 core for a week or so, so please give some thought
to the open issues listed in the STATUS file. Maybe
we should also lay out a roadmap of milestones for apreq-2?
Personally I believe we've surpassed at least one so far:
1) an operational core based solely on APR, with
a functional Apache2 environment.
The next one is within easy reach:
2) a basic test framework
a) simple unit tests for libapreq.so (the core).
b) simple Apache::Test tests for mod_apreq.
2a is already done (in t/), while 2b needs more work.
I already laid the foundation for 2b in glue/perl/.
Perhaps some of us perl guys can finish that part
off while working towards
3) Functional APREQ:: packages (perl glue for libapreq).
4) Apache::Request / Apache::Cookie ports using
the APREQ:: modules.
Any thoughts?
--
Joe Schaefer