mod_perl 2.0 and mod_dav
Hi Doug, do you have any plans for supporting mod_dav (which is now part of Apache 2.0) in mod_perl 2.0 ? The reason for my question is, that I am about to start to write a Perl interface to mod_dav, so you can create a custom repository (which let you store data and properties, or manage ACL or searching) in Perl. At the moment I will implement it for mod_dav 1.x, which works with Apache 1.3, but in the future it should also work with Apache 2.0. So I am asking now, to avoid to duplicate work. (If you planning to support mod_dav later on in mod_perl itself, I am happy to help out or to make the implementaion of this part) Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] A hack at first class filters
good work, let's consider everything before adding new code. below
lays out what i have in mind, combined with your approach...
direct C api mapping
Apache::register_output_filter($filtername, $callback, $filter_type)
Apache::register_input_filter($filtername, $callback, $filter_type)
filter_type can be one of:
Apache::FTYPE_CONTENT
Apache::FTYPE_HTTP_HEADER
Apache::FTYPE_TRANSCODE
Apache::FTYPE_CONNECTION
Apache::FTYPE_NETWORK
$r-add_output_filter($name, $ctx)
$c-add_output_filter($name, $ctx)
$r-add_input_filter($name, $ctx)
$c-add_input_filter($name, $ctx)
note: $ctx will default to NULL
directives
--
PerlInputFilterHandler
PerlOutputFilterHandler
each will be the equivalent of:
ap_register_{input,output}_filter($handler_name, $handler, $filter_type)
where:
$handler_name is the Perl name, at the moment is MODPERL_OUTPUT and
MODPERL_INPUT, would be easy to switch that to the handler name
$handler is the modperl C callback
$filter_type defaults to AP_FTYPE_CONTENT, subroutine attributes can
be used to specify the filter_types list above
based on attributes, add_{input,output}_filter may need to happen at
different times, e.g. input filters who want to filter headers +
content vs. input filters who want to filter only content
alternative to those directives would be:
PerlInputFilter
PerlOutputFilter
combined with:
SetInputFilter
SetOutputFilter
pros: can use Perl{Input,Output}Filter to register the filter in
httpd.conf, rather than using the API. can then call
$r-add_{input,output}_filter($filter_name) at request time
cons: in the common case, requires two directives that use the same
values (the $handler_name)
- and/or -
PerlSetInputFilter
PerlSetOutputFilter
as aliases for SetInputFilter, SetOutputFilter which also take care of
filter registration (which PerlInputFilter, PerlOutputFilter would
have done)
pros: similar to Set{Input,Output}Filter
only need to use one directive
cons: the filter module needs to register the filter in order to add
the filter at request time without using a directive
however: PerlModule Apache::FooFilter
where Apache::FooFilter registers the filter, can provide this
functionality without requiring new Perl{Input,Output}Filter
directives
- in any case -
with the C api mapping it should be possible for a PerlModule to
register the filter(s), then use the standard Set{Input,Output}Filter
directives and the add_{input,output}_filter api at request time.
note: no need to maintain a list of PerlFilters (like PerlModule,
PerlRequire) since the directives trigger modperl_handler_new(), just
like all other Perl*Handlers
{get,set,push}_handlers
---
would be nice for Perl{Input,Output}FilterHandler to work with the
modperl {get,set,push}_handlers api just like other Perl*Handlers
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Apache2:: namespace, prerequisite checking and CPAN listing
I'm going to talk about 3 issues here: namespace, prerequisite and CPAN
listing. All related to a single issue, a smooth move into the next
generation of mod_perl with as little confusion created as possible.
=head1 namespace
I think we've discussed this slightly before, but I wonder whether we want
to reserve Apache2:: namespace and have all the ported modules to move
into Apache2:: namespace, so it:
-- will not confuse users about whether the modules works with 2.0 only
-- force the authors to review their code in order to make it complient
with 2.0
I'm talking mainly about modules like Apache::Filter, Apache::Scoreboard
and similar which are tightly tied to mod_perl-1.3. I can foresee many
unncessary question on the list, because people will use wrong versions of
the modules.
The same goes for mod_perl-2.0 core modules. Having Apache2:: and Apache::
will allow to have both servers under the same /usr/lib/perl5 and will
allow OS distro to ship both versions and have them non-self-exclusive.
The only drawback is forgetting to type '2' when coding.
=head1 prerequisite
Another issue is having an unambiguous way to require a correct context
with something like:
Apache.pm:
--
sub require_mod_perl2 { 1; }
So if in your modules which work only with mod_perl-2.0 you will write:
Apache::KillerApp:
--
use strict;
Apache::require_mod_perl2();
and if the code is not running under mod_perl, this method will be simple
not available.
I prefer to have a standard accepted documented way to do that, rather
everyone trying to implement their own.
Also it would be nice to add now a method to 1.3 which will be also used
in 2.0 and allow to retrieve the version number easier than doing re:
$ENV{MOD_PERL} =~ /2/
this or similar technique will allow authors to have their code
working under 2.0 and 1.3, out of mod_perl. e.g.:
if (defined MOD_PERL_VERSION) {
if (defined MOD_PERL_VERSION = 3.0) {
# 3.0 specific code
} elsif (MOD_PERL_VERSION = 2.0){
# 2.0 specific code
} else {
# 1.x specific code
}
} else {
# non mod_perl code
}
(yeah, I do look forward into 3.0. Just like some people are still using
perl4, while perl6 is under development, there will be still people using
mod_perl-1.x, when we will talk about mod_perl 3.x.)
Until now a mere checking of $ENV{MOD_PERL} to figure out whether we are
in the mod_perl environment was good enough, but not anymore since we have
to be able to differentiate between 1.x and 2.x now, and using regex on
$ENV{MOD_PERL} is ugly and error prone. MOD_PERL_VERSION constant seems
like a much nicer way to do this.
=head1 CPAN listings
In any case we will have to start a new list of modules on
perl.apache.org, and list modules which work with 2.0 (and possibly with
1.3).
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl 2.0 and mod_dav
Hi Doug, if you implement an interface to mod_dav that works with both 1.x and 2.x, that would be great and then we can skip the inclusion of an interface bundled with modperl-2.0. or we could have two, your 1.x version on cpan, and a 2.x version bundled with modperl-2.0. i'm not sure which would be the best approach, not having looked at the differences between 1.x and 2.x mod_dav. At the moment there are differences, but they aren't so great, but Greg is about to change the some of the interfaces in 2.0. My first step would be to implement a version of 1.x (but keep 2.0) in mind (Because I need it now in a production environment). When things has settled a little bit, I would port this to 2.0. Since I plan to auto generate the interface stuff, it is hopefully not so much work to get it running with 2.0. When I start to work on the 2.0 version, we should again talk about how close we like to intergrate it into mod_perl 2.0. For me both solutions (separate CPAN module or ship with mod_perl) are ok. Gerald P.S. Are you going to the YAPC europe in Amsterdamm and/or the ApacheCon in Dublin. If not I would submit a proposal to talk about mod_perl 2.0 on these two conferences. (maybe I can take your slides to save some work :-) - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl 2.0 and mod_dav
On Fri, 25 May 2001, Gerald Richter wrote: At the moment there are differences, but they aren't so great, but Greg is about to change the some of the interfaces in 2.0. My first step would be to implement a version of 1.x (but keep 2.0) in mind (Because I need it now in a production environment). When things has settled a little bit, I would port this to 2.0. Since I plan to auto generate the interface stuff, it is hopefully not so much work to get it running with 2.0. When I start to work on the 2.0 version, we should again talk about how close we like to intergrate it into mod_perl 2.0. For me both solutions (separate CPAN module or ship with mod_perl) are ok. ok, sounds good, let's revist that down the road. Gerald P.S. Are you going to the YAPC europe in Amsterdamm and/or the ApacheCon in Dublin. If not I would submit a proposal to talk about mod_perl 2.0 on these two conferences. (maybe I can take your slides to save some work :-) i am planning to submit a talk for dublin, but not yapc europe. you're welcome to use my 2.0 slides for that if you like. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
