You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Gerald Richter <ri...@ecos.de> on 2001/05/24 20:55:17 UTC
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 Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: automaticly created XS in mod_perl 2.0
Posted by Doug MacEachern <do...@covalent.net>.
On Mon, 28 May 2001, Gerald Richter wrote:
>
> > this looks like one of the problems the hacked version of C::Scan (at
> > perl.apache.org/~dougm/) fixes.
> >
>
> I have the C::Scan from perl.apache.org/~dougm/ . I just rechecked to be
> sure. So maybe you have done some more fixes and not uploaded it to
> perl.apache.org/~dougm/ ? Also the C::Scan->VERSION(0.75); inside
> Apache::ParseSource should give use warning, if I have the wrong version...
hmm, no the fix was added to that version several weeks (months?) ago.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: automaticly created XS in mod_perl 2.0
Posted by Gerald Richter <ri...@ecos.de>.
> this looks like one of the problems the hacked version of C::Scan (at
> perl.apache.org/~dougm/) fixes.
>
I have the C::Scan from perl.apache.org/~dougm/ . I just rechecked to be
sure. So maybe you have done some more fixes and not uploaded it to
perl.apache.org/~dougm/ ? Also the C::Scan->VERSION(0.75); inside
Apache::ParseSource should give use warning, if I have the wrong version...
Gerald
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: automaticly created XS in mod_perl 2.0
Posted by Doug MacEachern <do...@covalent.net>.
On Sun, 27 May 2001, Gerald Richter wrote:
> I tried this already. Addtionaly to add the dav_ prefix, I had to add the
> mod_dav.h to the include files (because it's not in the include directory).
>
> I parses the function correctly, but not the callbacks. As far as I seen,
> you don't create the callbacks automaticly, is this right ?
right.
> The implementation of a mod_dav Perl backend will be about 50% callbacks
> into Perl, so I like to generate them also automaticly.
oh wow, didn't know there's so many callbacks.
> > more work would be involved to get the current tools in shape to
> > generate the client front end to neon.
> >
>
> My quick and dirty script does this at the moment for neon. It generates all
> function call and callbacks (there is no handwritten code in HTTP::Webdav
> :-). Now I like to bring these both together (at least parts of it, other
> parts will stay divided, because my time is limited) and I like to create
> also the mod_dav 1.x backend with these scripts.
>
> I just will play a little bit around (together with Philippe) and we will
> get back to you as soon as we have any results. I think we start to make a
> base class for ModPerl/Apache::PasrseSource, which also is able to parser
> typedefs, and give mode detailed information about callbacks (i.e. splitting
> out the args of the callback function).
ok, sounds good.
> Gerald
>
> P.S. To get uitl/source_scan.pl working I had to add a
>
> use ModPerl::WarpXS ;
right, i've been meaning to fix that.
> and the ModPerl::ParseSource->write_functions_pm dies. See the output from
> the Perl debugger below. I currently use Perl 5.6.1.
>
> main::(util/source_scan.pl:22): $p = ModPerl::ParseSource->new(@ARGV);
> DB<1> n
> main::(util/source_scan.pl:24): $p->parse;
> DB<1> n
> main::(util/source_scan.pl:26): $p->write_functions_pm;
> DB<1> n
> In file included from .apache_includes:4,
> from :1:
> xs/modperl_xs_sv_convert.h:288: warning:
> p_xs_sv2_r' redefined
> xs/modperl_xs_util.h:6: warning: this is the location of the previous
> definition
> In file included from .apache_includes:4,
> from :1:
> xs/modperl_xs_sv_convert.h:288: warning:
> p_xs_sv2_r' redefined
> xs/modperl_xs_util.h:6: warning: this is the location of the previous
> definition
> panic: multiple types without intervening comma in
> regexp*( *regcomp_t ) (register PerlInterpreter *my_perl , char*
> exp, char* xend, PMOP* pm)
> whited-out as
> regexp*( *regcomp_t )
> ( )
this looks like one of the problems the hacked version of C::Scan (at
perl.apache.org/~dougm/) fixes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: automaticly created XS in mod_perl 2.0
Posted by Gerald Richter <ri...@ecos.de>.
>
> the current tools should work for generating a mod_dav backend with 2.0
> i think we just need to add the dav_ prefix to Apache::ParseSource so
> mod_dav.h is parsed into the Apache::{Function,Structure}Table.
>
I tried this already. Addtionaly to add the dav_ prefix, I had to add the
mod_dav.h to the include files (because it's not in the include directory).
I parses the function correctly, but not the callbacks. As far as I seen,
you don't create the callbacks automaticly, is this right ?
The implementation of a mod_dav Perl backend will be about 50% callbacks
into Perl, so I like to generate them also automaticly.
> more work would be involved to get the current tools in shape to
> generate the client front end to neon.
>
My quick and dirty script does this at the moment for neon. It generates all
function call and callbacks (there is no handwritten code in HTTP::Webdav
:-). Now I like to bring these both together (at least parts of it, other
parts will stay divided, because my time is limited) and I like to create
also the mod_dav 1.x backend with these scripts.
I just will play a little bit around (together with Philippe) and we will
get back to you as soon as we have any results. I think we start to make a
base class for ModPerl/Apache::PasrseSource, which also is able to parser
typedefs, and give mode detailed information about callbacks (i.e. splitting
out the args of the callback function).
Gerald
P.S. To get uitl/source_scan.pl working I had to add a
use ModPerl::WarpXS ;
and the ModPerl::ParseSource->write_functions_pm dies. See the output from
the Perl debugger below. I currently use Perl 5.6.1.
main::(util/source_scan.pl:22): $p = ModPerl::ParseSource->new(@ARGV);
DB<1> n
main::(util/source_scan.pl:24): $p->parse;
DB<1> n
main::(util/source_scan.pl:26): $p->write_functions_pm;
DB<1> n
In file included from .apache_includes:4,
from :1:
xs/modperl_xs_sv_convert.h:288: warning:
p_xs_sv2_r' redefined
xs/modperl_xs_util.h:6: warning: this is the location of the previous
definition
In file included from .apache_includes:4,
from :1:
xs/modperl_xs_sv_convert.h:288: warning:
p_xs_sv2_r' redefined
xs/modperl_xs_util.h:6: warning: this is the location of the previous
definition
panic: multiple types without intervening comma in
regexp*( *regcomp_t ) (register PerlInterpreter *my_perl , char*
exp, char* xend, PMOP* pm)
whited-out as
regexp*( *regcomp_t )
( )
Expecting parenth after identifier in egcomp_t *
Perl_Tregcompp_ptr(register PerlInterpreter *my_perl )'
after egcomp_t ' at /opt/perlt5.6.1/lib/site_perl/5.6.1/C/Scan.pm line
783.
C::Scan::do_declaration('extern ^Iregcomp_t *
Perl_Tregcompp_ptr(register PerlInterpre...', 'HASH(0x881669c)',
'HASH(0x8815620)') called at /opt/perlt5.6.1/lib/site_perl/5.6.1/C/Scan.pm
line 738
C::Scan::do_declarations('ARRAY(0x87f113c)', 'HASH(0x881669c)',
'HASH(0x8815620)') called at
/opt/perlt5.6.1/lib/site_perl/5.6.1/Data/Flow.pm line 69
Data::Flow::request('Apache::ParseSource::Scan=ARRAY(0x87f0cec)',
'parsed_fdecls') called at /opt/perlt5.6.1/lib/site_perl/5.6.1/Data/Flow.pm
line 39
Data::Flow::get('Apache::ParseSource::Scan=ARRAY(0x87f0cec)',
'parsed_fdecls') called at lib/Apache/ParseSource.pm line 49
Apache::ParseSource::Scan::get('Apache::ParseSource::Scan=ARRAY(0x87f0cec)',
'parsed_fdecls') called at lib/Apache/ParseSource.pm line 290
Apache::ParseSource::get_functions('ModPerl::ParseSource=HASH(0x8a9de1c)')
called at lib/Apache/ParseSource.pm line 368
Apache::ParseSource::write_functions_pm('ModPerl::ParseSource=HASH(0x8a9de1c
)', 'FunctionTable.pm', 'ModPerl::FunctionTable') called at
lib/ModPerl/ParseSource.pm line 40
ModPerl::ParseSource::write_functions_pm('ModPerl::ParseSource=HASH(0x8a9de1
c)') called at util/source_scan.pl line 26Debugged program terminated. Use
q to quit or R to restart,
use O inhibit_exit to avoid stopping after program termination,
h q, h R or h O to get additional info.
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: automaticly created XS in mod_perl 2.0
Posted by Doug MacEachern <do...@covalent.net>.
On Fri, 25 May 2001, Gerald Richter wrote:
> ok, I give it a try. I don't expect it to be a real general tool (I think I
> don't have the time to really abstract all the work you have done in a more
> general way), but something that I can use to build the mod_dav backend for
> mod_perl 1.x and 2.x.
the current tools should work for generating a mod_dav backend with 2.0
i think we just need to add the dav_ prefix to Apache::ParseSource so
mod_dav.h is parsed into the Apache::{Function,Structure}Table.
more work would be involved to get the current tools in shape to
generate the client front end to neon.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: automaticly created XS in mod_perl 2.0
Posted by Gerald Richter <ri...@ecos.de>.
> i intended to make the mod_perl-2.0 code generation tied tight to
> Apache/mod_perl. i didn't want to build a generic tool, like another swig
> or Inline.pm, i only wanted something generic enough to work with the
> entire Apache/APR api, along with Apache modules like mod_dav, mod_proxy,
> etc. my biggest fear in making it more generic was the time it would
> take. but if you're seeing a use/need outside of the Apache/mod_perl
> scope, then by all means, go for it :) i'd be willing to make
> adjustments/use a more generic base class in modperl-2.0.
>
ok, I give it a try. I don't expect it to be a real general tool (I think I
don't have the time to really abstract all the work you have done in a more
general way), but something that I can use to build the mod_dav backend for
mod_perl 1.x and 2.x.
I let you know when I have some results and then we can discuss how this
fits into mod_perl 2.0 or not
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: automaticly created XS in mod_perl 2.0
Posted by Doug MacEachern <do...@covalent.net>.
i intended to make the mod_perl-2.0 code generation tied tight to
Apache/mod_perl. i didn't want to build a generic tool, like another swig
or Inline.pm, i only wanted something generic enough to work with the
entire Apache/APR api, along with Apache modules like mod_dav, mod_proxy,
etc. my biggest fear in making it more generic was the time it would
take. but if you're seeing a use/need outside of the Apache/mod_perl
scope, then by all means, go for it :) i'd be willing to make
adjustments/use a more generic base class in modperl-2.0.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
automaticly created XS in mod_perl 2.0
Posted by Gerald Richter <ri...@ecos.de>.
Hi Doug,
for my implemetation of the interface to mod_dav I again looked thru your
code that generates the XS for mod_perl 2.0. I have done this the first time
when I implemented my HTTP::Webdav (which is a webdav client and will be
soon on CPAN). For this first project that does automaticly generate XS from
C I decided, that your modules are too much connected to the internals of
Apache and wrote my own quick and dirty script that now creates all the XS
glue code for the API and the callbacks. Now for the mod_dav backend, I took
again a look at the XS generation in mod_perl and thought it would be a good
idea to make it a little bit more general, so it could be used outside
mod_perl. My idea is to make a base class (e.g. ExtUtils::XSMaker;
suggestions for better names are welcome), that implements all the general
stuff and your mod_perl/Apache class inherit from this base class and
implement the mod_perl specific stuff. This way another application could
also use the base class and use it without Apache. The idea behind this is,
that mod_dav should now run with mod_perl 1.x, but later with mod_perl 2.x.
If we can make the XS generation stuff more general, I could use it right
now and the port to Apache/mod_perl 2.0 would be much easier.
I know this will be a lot of work, but you already have done a lot of work
for the XS generation and I don't like to reimplement it. What do you think,
should I give it a try ? If I start such a separation, would you take it
into mod_perl, so we can use the same code base, or is this for whatever
reasons a bad idea ?
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl 2.0 and mod_dav
Posted by Doug MacEachern <do...@covalent.net>.
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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl 2.0 and mod_dav
Posted by Gerald Richter <ri...@ecos.de>.
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 Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl 2.0 and mod_dav
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 24 May 2001, Gerald Richter wrote:
> Hi Doug,
>
> do you have any plans for supporting mod_dav (which is now part of Apache
> 2.0) in mod_perl 2.0 ?
yes, i would like to have an auto-generated interface for 2.0, but have
not looked at mod_dav yet.
> 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.
cool!
> 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)
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org