You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Andy Wardley <ab...@andywardley.com> on 2002/06/18 11:31:06 UTC
Naming convention for Apache 2 modules.
I've been playing around with Apache 2 and mod_perl 1.99 and considering
the changes I'll need to make to Apache::Template to make it play nicely
under the new world order.
Given that I want to continue to support Apache::Template for v1 users,
should I create another module, say Apache2::Template, or is there some
preferred approach to v1/v2 compatabilities that I should consider?
I've read the compat.html doc and understand that I might be able to
support Apache::Template as it is with the help of the Apache2 compatability
module. However, I'm sure there are some parts, server/dir merging in
particular (which seem to be broken in v1 anyway), which are going to need
new implementations for v2, so I figure it's probably worth forking the
codebase sooner rather than later.
A
Re: Naming convention for Apache 2 modules.
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 19 Jun 2002, Stas Bekman wrote:
> Randy Kobes wrote:
> >
> > To maintain a one-to-one correspondence between module and
> > distribution name, another approach might be, within the same
> > distribution, to maintain two separate trees of the code
> > (corresponding to mod_perl-1 and mod_perl-2). Then, at the 'perl
> > Makefile.PL' stage, decide through user input which tree to use.
> > Some distributions, eg, Scalar-List-Utils, do this to build an XS
> > version of a module or use a pure Perl version. One could even
> > try to make an intelligent guess, based on the httpd version,
> > which would be the default.
>
> But that will make non-interactive installations impossible.
>
> May be we should rely on environment variables? So if we do
>
> % MODPERLGEN=2 perl Makefile.PL
> or
> % MODPERLGEN=2 perl -MCPAN -eshell
>
> and mod_perl core will provide a hook for Makefile.PL that will check
> for this env variable and if set won't ask any questions and do the
> suggested install, otherwise the question will be asked. In any case
> it's better to have this standard hook and not have each author trying
> to figure out how to do that black magick.
Or perhaps check for the existence of the Apache2 module, and if
present, assume mod_perl-2? This may not always do what the user
wants, but may be a reasonable default, which could be then be
overridden via an environment variable, as above.
> But it's not trivial to have two different install trees under the same
> source tree, because MakeMaker will try to build both.
That's true ... One way is to have some top-level Makefile.PL
that just sets the 'NAME' and 'DIR' attributes, with DIR
instructing ExtUtils::MakeMaker which directory (eg, lib1/ or
lib2/) to use, under which is the desired Makefile.PL that does
the rest of the building.
best regards,
randy
Re: Naming convention for Apache 2 modules.
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Wed, 19 Jun 2002, Stas Bekman wrote:
>
>
>>Andreas J. Koenig wrote:
>>
>>>>>>>>On Tue, 18 Jun 2002 23:27:03 +0800, Stas Bekman <st...@stason.org> said:
>>>>>>>
>>> > Ian D. Stewart wrote:
>>> >> On 2002.06.18 09:57 Stas Bekman wrote:
>>> >>
>>> >>> [CC'ing Andreas again]
>>> >>>
>>> >>>> Stas is right. The only problem I see with MP_INST_APACHE2 is the
>>> >>>> fact that using the CPAN.pm module to download the module would
>>> >>>> fetch the newest version of the module, regardless of whether you
>>> >>>> wanted the one for mod_perl 2.0 or mod_perl 1.0.
>>> >>>
>>> >>>
>>> >>> That's true :(
>>> >>>
>>> >>> I hope Andreas can make PAUSE index both versions so CPAN.pm will
>>> >>> display the two, but for that we need some sort convention so PAUSE
>>> >>> can use to decide on. Andreas, any ideas regarding this issue?
>>>
>>>Sorry, no. The CPAN indexer is based on the assumption that there are
>>>no branches of code necessary and everything can be coded in a
>>>backwards compatible way.
>>
>>But this can be added, right? Just need to think of a working model.
>
>
> To maintain a one-to-one correspondence between module and
> distribution name, another approach might be, within the same
> distribution, to maintain two separate trees of the code
> (corresponding to mod_perl-1 and mod_perl-2). Then, at the 'perl
> Makefile.PL' stage, decide through user input which tree to use.
> Some distributions, eg, Scalar-List-Utils, do this to build an XS
> version of a module or use a pure Perl version. One could even
> try to make an intelligent guess, based on the httpd version,
> which would be the default.
But that will make non-interactive installations impossible.
May be we should rely on environment variables? So if we do
% MODPERLGEN=2 perl Makefile.PL
or
% MODPERLGEN=2 perl -MCPAN -eshell
and mod_perl core will provide a hook for Makefile.PL that will check
for this env variable and if set won't ask any questions and do the
suggested install, otherwise the question will be asked. In any case
it's better to have this standard hook and not have each author trying
to figure out how to do that black magick.
But it's not trivial to have two different install trees under the same
source tree, because MakeMaker will try to build both.
--
__________________________________________________________________
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: Naming convention for Apache 2 modules.
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 19 Jun 2002, Stas Bekman wrote:
> Andreas J. Koenig wrote:
> >>>>>>On Tue, 18 Jun 2002 23:27:03 +0800, Stas Bekman <st...@stason.org> said:
> >>>>>
> >
> > > Ian D. Stewart wrote:
> > >> On 2002.06.18 09:57 Stas Bekman wrote:
> > >>
> > >>> [CC'ing Andreas again]
> > >>>
> > >>>> Stas is right. The only problem I see with MP_INST_APACHE2 is the
> > >>>> fact that using the CPAN.pm module to download the module would
> > >>>> fetch the newest version of the module, regardless of whether you
> > >>>> wanted the one for mod_perl 2.0 or mod_perl 1.0.
> > >>>
> > >>>
> > >>> That's true :(
> > >>>
> > >>> I hope Andreas can make PAUSE index both versions so CPAN.pm will
> > >>> display the two, but for that we need some sort convention so PAUSE
> > >>> can use to decide on. Andreas, any ideas regarding this issue?
> >
> > Sorry, no. The CPAN indexer is based on the assumption that there are
> > no branches of code necessary and everything can be coded in a
> > backwards compatible way.
>
> But this can be added, right? Just need to think of a working model.
To maintain a one-to-one correspondence between module and
distribution name, another approach might be, within the same
distribution, to maintain two separate trees of the code
(corresponding to mod_perl-1 and mod_perl-2). Then, at the 'perl
Makefile.PL' stage, decide through user input which tree to use.
Some distributions, eg, Scalar-List-Utils, do this to build an XS
version of a module or use a pure Perl version. One could even
try to make an intelligent guess, based on the httpd version,
which would be the default.
best regards,
randy kobes
Re: Naming convention for Apache 2 modules.
Posted by Stas Bekman <st...@stason.org>.
Andreas J. Koenig wrote:
>>>>>>On Tue, 18 Jun 2002 23:27:03 +0800, Stas Bekman <st...@stason.org> said:
>>>>>
>
> > Ian D. Stewart wrote:
> >> On 2002.06.18 09:57 Stas Bekman wrote:
> >>
> >>> [CC'ing Andreas again]
> >>>
> >>>> Stas is right. The only problem I see with MP_INST_APACHE2 is the
> >>>> fact that using the CPAN.pm module to download the module would
> >>>> fetch the newest version of the module, regardless of whether you
> >>>> wanted the one for mod_perl 2.0 or mod_perl 1.0.
> >>>
> >>>
> >>> That's true :(
> >>>
> >>> I hope Andreas can make PAUSE index both versions so CPAN.pm will
> >>> display the two, but for that we need some sort convention so PAUSE
> >>> can use to decide on. Andreas, any ideas regarding this issue?
>
> Sorry, no. The CPAN indexer is based on the assumption that there are
> no branches of code necessary and everything can be coded in a
> backwards compatible way.
But this can be added, right? Just need to think of a working model.
> >> An alternative approach could involve placing the functionality
> >> specific to mod_perl 2.0 in a sub-module, then conditionally
> >> importing that submodule depending on the value of
> >> $Apache::Registry::VERSION.
>
> > This is not the case for the complex modules involving C, XS, custom
> > directives and lots of code. As a module author I'd rather have a
> > separate code base without gazillions of #ifdefs and perl side version
> > checking.
>
> I'd suspect that if it needs many ifdefs that there's something wrong.
> A shot in the dark, because I'm not familiar with mod_perl-2: could
> not something like ppport.h for apache-module-writers be developed?
Not really, Apache 2.0 API has changed a lot compared to 1.3, certain
interfaces were completely dropped. So we do provide a pure-perl back
compatibility layer, but you don't want to use this for performance
reasons, as certainly the C implementations are significantly faster.
The compat layer is there for the transition period, but at some point
the code will have to be ported to use 2.0 APIs.
mod_perl does provide some internal (C-level) back-compatibilities where
it was possible.
> > It's very unlikely that you will be able to extract mod_perl 2.0
> > specific functionality into a sub-module, because most of the Apache::
> > modules are using the mod_perl 2.0 API everywhere in the code.
>
> Sorry, at the moment I have no idea how CPAN indexer could help here.
what if the distro name includes Apache2? So for example we get
Apache2-Template-1.06 and Apache-Template-0.06? The package name will
stay the same Apache::Template. I realize that we cannot rely on the
version to be 1.xx and 2.xx, and deduct the info from here, because some
modules are 0.xx, others 1.xx and probably there are some 2.xx.
__________________________________________________________________
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: Naming convention for Apache 2 modules.
Posted by "Andreas J. Koenig" <an...@anima.de>.
>>>>> On Tue, 18 Jun 2002 23:27:03 +0800, Stas Bekman <st...@stason.org> said:
> Ian D. Stewart wrote:
>> On 2002.06.18 09:57 Stas Bekman wrote:
>>
>>> [CC'ing Andreas again]
>>>
>>>> Stas is right. The only problem I see with MP_INST_APACHE2 is the
>>>> fact that using the CPAN.pm module to download the module would
>>>> fetch the newest version of the module, regardless of whether you
>>>> wanted the one for mod_perl 2.0 or mod_perl 1.0.
>>>
>>>
>>> That's true :(
>>>
>>> I hope Andreas can make PAUSE index both versions so CPAN.pm will
>>> display the two, but for that we need some sort convention so PAUSE
>>> can use to decide on. Andreas, any ideas regarding this issue?
Sorry, no. The CPAN indexer is based on the assumption that there are
no branches of code necessary and everything can be coded in a
backwards compatible way.
>> An alternative approach could involve placing the functionality
>> specific to mod_perl 2.0 in a sub-module, then conditionally
>> importing that submodule depending on the value of
>> $Apache::Registry::VERSION.
> This is not the case for the complex modules involving C, XS, custom
> directives and lots of code. As a module author I'd rather have a
> separate code base without gazillions of #ifdefs and perl side version
> checking.
I'd suspect that if it needs many ifdefs that there's something wrong.
A shot in the dark, because I'm not familiar with mod_perl-2: could
not something like ppport.h for apache-module-writers be developed?
> It's very unlikely that you will be able to extract mod_perl 2.0
> specific functionality into a sub-module, because most of the Apache::
> modules are using the mod_perl 2.0 API everywhere in the code.
Sorry, at the moment I have no idea how CPAN indexer could help here.
--
andreas
Re: Naming convention for Apache 2 modules.
Posted by Stas Bekman <st...@stason.org>.
Ian D. Stewart wrote:
> On 2002.06.18 09:57 Stas Bekman wrote:
>
>> [CC'ing Andreas again]
>>
>>> Stas is right. The only problem I see with MP_INST_APACHE2 is the
>>> fact that using the CPAN.pm module to download the module would fetch
>>> the newest version of the module, regardless of whether you wanted
>>> the one for mod_perl 2.0 or mod_perl 1.0.
>>
>>
>> That's true :(
>>
>> I hope Andreas can make PAUSE index both versions so CPAN.pm will
>> display the two, but for that we need some sort convention so PAUSE
>> can use to decide on. Andreas, any ideas regarding this issue?
>
>
> An alternative approach could involve placing the functionality specific
> to mod_perl 2.0 in a sub-module, then conditionally importing that
> submodule depending on the value of $Apache::Registry::VERSION.
This is not the case for the complex modules involving C, XS, custom
directives and lots of code. As a module author I'd rather have a
separate code base without gazillions of #ifdefs and perl side version
checking.
It's very unlikely that you will be able to extract mod_perl 2.0
specific functionality into a sub-module, because most of the Apache::
modules are using the mod_perl 2.0 API everywhere in 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: Naming convention for Apache 2 modules.
Posted by "Ian D. Stewart" <id...@compuvative.com>.
On 2002.06.18 09:57 Stas Bekman wrote:
> [CC'ing Andreas again]
>
>> Stas is right. The only problem I see with MP_INST_APACHE2 is the
>> fact that using the CPAN.pm module to download the module would
>> fetch the newest version of the module, regardless of whether you
>> wanted the one for mod_perl 2.0 or mod_perl 1.0.
>
> That's true :(
>
> I hope Andreas can make PAUSE index both versions so CPAN.pm will
> display the two, but for that we need some sort convention so PAUSE
> can use to decide on. Andreas, any ideas regarding this issue?
An alternative approach could involve placing the functionality
specific to mod_perl 2.0 in a sub-module, then conditionally importing
that submodule depending on the value of $Apache::Registry::VERSION.
Ian
Re: Naming convention for Apache 2 modules.
Posted by Stas Bekman <st...@stason.org>.
[CC'ing Andreas again]
> Stas is right. The only problem I see with MP_INST_APACHE2 is the fact
> that using the CPAN.pm module to download the module would fetch the
> newest version of the module, regardless of whether you wanted the one
> for mod_perl 2.0 or mod_perl 1.0.
That's true :(
I hope Andreas can make PAUSE index both versions so CPAN.pm will
display the two, but for that we need some sort convention so PAUSE can
use to decide on. Andreas, any ideas regarding this issue?
Thanks!
__________________________________________________________________
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: Naming convention for Apache 2 modules.
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Tue, 18 Jun 2002, Per Einar Ellefsen wrote:
>
>
>>Stas is right. The only problem I see with MP_INST_APACHE2 is the fact that
>>using the CPAN.pm module to download the module would fetch the newest
>>version of the module, regardless of whether you wanted the one for
>>mod_perl 2.0 or mod_perl 1.0.
>
>
> one CPAN.pm solution for mod_perl is:
>
> to install the 1.xx version (there is no Apache.pm in 2.xx):
> cpan> install Apache
>
> to install the 2.xx version:
> cpan> install Apache2
that will work for the mod_perl core. We are also talking about third
party modules which may ship different packages for 1.0 and 2.0, keeping
the same name of the module.
--
__________________________________________________________________
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: Naming convention for Apache 2 modules.
Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 18 Jun 2002, Per Einar Ellefsen wrote:
> Stas is right. The only problem I see with MP_INST_APACHE2 is the fact that
> using the CPAN.pm module to download the module would fetch the newest
> version of the module, regardless of whether you wanted the one for
> mod_perl 2.0 or mod_perl 1.0.
one CPAN.pm solution for mod_perl is:
to install the 1.xx version (there is no Apache.pm in 2.xx):
cpan> install Apache
to install the 2.xx version:
cpan> install Apache2
Re: Naming convention for Apache 2 modules.
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 13:26 18.06.2002, Stas Bekman wrote:
>Andy Wardley wrote:
>>I've been playing around with Apache 2 and mod_perl 1.99 and considering
>>the changes I'll need to make to Apache::Template to make it play nicely
>>under the new world order.
>>Given that I want to continue to support Apache::Template for v1 users,
>>should I create another module, say Apache2::Template, or is there some
>>preferred approach to v1/v2 compatabilities that I should consider?
>>I've read the compat.html doc and understand that I might be able to
>>support Apache::Template as it is with the help of the Apache2 compatability
>>module. However, I'm sure there are some parts, server/dir merging in
>>particular (which seem to be broken in v1 anyway), which are going to need
>>new implementations for v2, so I figure it's probably worth forking the
>>codebase sooner rather than later.
>
>No Andy, no need to rename, you can either maintain the two in one module
>(if it's not too messy, which is the case if you have a lot of C) or just
>two different versions which will install themselves into different dirs.
>
>Here are some preliminary notes discussing these issues.
>http://perl.apache.org/release/docs/2.0/devel/porting_from_1.x/porting_from_1.x.html
>Feel free to help improving on these.
>
>Of course the MP_INST_APACHE2=1 mechanism needs to become available to to
>other module writers.
Stas is right. The only problem I see with MP_INST_APACHE2 is the fact that
using the CPAN.pm module to download the module would fetch the newest
version of the module, regardless of whether you wanted the one for
mod_perl 2.0 or mod_perl 1.0.
--
Per Einar Ellefsen
per.einar@skynet.be
Re: Naming convention for Apache 2 modules.
Posted by Stas Bekman <st...@stason.org>.
Andy Wardley wrote:
> I've been playing around with Apache 2 and mod_perl 1.99 and considering
> the changes I'll need to make to Apache::Template to make it play nicely
> under the new world order.
>
> Given that I want to continue to support Apache::Template for v1 users,
> should I create another module, say Apache2::Template, or is there some
> preferred approach to v1/v2 compatabilities that I should consider?
>
> I've read the compat.html doc and understand that I might be able to
> support Apache::Template as it is with the help of the Apache2 compatability
> module. However, I'm sure there are some parts, server/dir merging in
> particular (which seem to be broken in v1 anyway), which are going to need
> new implementations for v2, so I figure it's probably worth forking the
> codebase sooner rather than later.
No Andy, no need to rename, you can either maintain the two in one
module (if it's not too messy, which is the case if you have a lot of C)
or just two different versions which will install themselves into
different dirs.
Here are some preliminary notes discussing these issues.
http://perl.apache.org/release/docs/2.0/devel/porting_from_1.x/porting_from_1.x.html
Feel free to help improving on these.
Of course the MP_INST_APACHE2=1 mechanism needs to become available to
to other module writers.
__________________________________________________________________
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: Naming convention for Apache 2 modules.
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 11:31 18.06.2002, Andy Wardley wrote:
>I've been playing around with Apache 2 and mod_perl 1.99 and considering
>the changes I'll need to make to Apache::Template to make it play nicely
>under the new world order.
>
>Given that I want to continue to support Apache::Template for v1 users,
>should I create another module, say Apache2::Template, or is there some
>preferred approach to v1/v2 compatabilities that I should consider?
>
>I've read the compat.html doc and understand that I might be able to
>support Apache::Template as it is with the help of the Apache2 compatability
>module. However, I'm sure there are some parts, server/dir merging in
>particular (which seem to be broken in v1 anyway), which are going to need
>new implementations for v2, so I figure it's probably worth forking the
>codebase sooner rather than later.
What about making the 2.0 module follow the conventions I posted about
earlier? Something like Apache::Framework::Template?
--
Per Einar Ellefsen
per.einar@skynet.be