[RT] what's the roadmap?
Now that we've got a release of libapreq2 out the door, it's a good time to think about the direction of the project going forward. So let's take a look at where we are now, and figure out where we want to be in a year from now, and map out some goals for getting there. Right now we have a handful of active committers, with myself volunteering to play RM; pgollucci has volunteered to improve the website docs, which are priorities now, and randyk supports the win32 platform. Other committers like maxk provide review and oversight, although not for the release tarball this time. This time we got lots of help from httpd'ers, who have expressed an interest in seeing this list absorbed into [EMAIL PROTECTED] I think that's a good idea, so long as [EMAIL PROTECTED] can withstand the occasional question about our perl glue. Someday I'd actually like to see trunk/glue/perl moved over to mod_perl's trunk, and our C code folded into httpd somehow, but that may take some time doing. Anyways, since we're mapping out goals in this thread I think that should be our long-term one. Getting there would involve moving this list into [EMAIL PROTECTED], and our commit list to [EMAIL PROTECTED]; tackling the automake problem, writing better docs/webpages, improving the maintainability of the codebase. We'd have to stop trying to be an aggregation point for the httpd and mod-perl communities, and instead work more directly within each community. I think people are generally too busy with their respective projects to build this community into a separate TLP, and our scope can stay smaller without trying to be a separate project: we can just be about the Perl and C apis as we have always been. Glue writers for other languages seem to be content with libapreq1 for the most part, and haven't been motivated to contribute directly to the libapreq2 codebase. So what are your thoughts about the future of apreq? -- Joe Schaefer
Re: [RT] what's the roadmap?
I'd love to see libapreq2 in httpd base and the perl glue in mod_perl asap i think it would be best for all three projects. On Feb 20, 2006, at 2:25 PM, Joe Schaefer wrote: Now that we've got a release of libapreq2 out the door, it's a good time to think about the direction of the project going forward. So let's take a look at where we are now, and figure out where we want to be in a year from now, and map out some goals for getting there. Right now we have a handful of active committers, with myself volunteering to play RM; pgollucci has volunteered to improve the website docs, which are priorities now, and randyk supports the win32 platform. Other committers like maxk provide review and oversight, although not for the release tarball this time. This time we got lots of help from httpd'ers, who have expressed an interest in seeing this list absorbed into [EMAIL PROTECTED] I think that's a good idea, so long as [EMAIL PROTECTED] can withstand the occasional question about our perl glue. Someday I'd actually like to see trunk/glue/perl moved over to mod_perl's trunk, and our C code folded into httpd somehow, but that may take some time doing. Anyways, since we're mapping out goals in this thread I think that should be our long-term one. Getting there would involve moving this list into [EMAIL PROTECTED], and our commit list to [EMAIL PROTECTED]; tackling the automake problem, writing better docs/webpages, improving the maintainability of the codebase. We'd have to stop trying to be an aggregation point for the httpd and mod-perl communities, and instead work more directly within each community. I think people are generally too busy with their respective projects to build this community into a separate TLP, and our scope can stay smaller without trying to be a separate project: we can just be about the Perl and C apis as we have always been. Glue writers for other languages seem to be content with libapreq1 for the most part, and haven't been motivated to contribute directly to the libapreq2 codebase. So what are your thoughts about the future of apreq? -- Joe Schaefer
Re: [RT] what's the roadmap?
Eli Marmor wrote: Hi Joe, First, congrats and thanks for 2-2.07. Everything sounds great (well, maybe except for the words that may take some time doing ;-) My question: currently, there is one big libapreq2-2.07.tar.gz; Why don't we split it into two files, one for the C glue, a candidate for the integration into httpd (or apr/apr-util?), and the second, Perl glue, depnding on the former, a candidate for integration into mod_perl/CPAN? ++1 and I'd be happy to help review anyone's efforts in this direction. I believe that axing the Perl from the base library may clean the fears of the httpders, while having the C in httpd/apr and having only Perl in the Perl-glue (that depends on a standard stuff which was integrated into httpd/apr) may help the mod_perl guys to integrate it. You know, I know, Joe knows apreq's c core isn't all that perl centric, but I don't think the [EMAIL PROTECTED] community is really aware of this fact. This is a good suggestion. Bill
Re: [RT] what's the roadmap?
Geoffrey Young wrote: I think that's a good idea, so long as [EMAIL PROTECTED] can withstand the occasional question about our perl glue. Someday I'd actually like to see trunk/glue/perl moved over to mod_perl's trunk, and our C code folded into httpd somehow, but that may take some time doing. in principle I don't mind this idea, and we can certainly consider taking the perl glue under the mod_perl project. I guess the more difficult part would be in deciding how to package things so that it's the least complex for the end user. From the experiences I have had talking to people on the mod_perl list about mod_perl2, the most common issue for users coming from mod_perl 1 is how to handle the request data other than using $r-args or CGI. I think that having the perl glue install alongside the standard mod_perl libraries would be ideal. IMHO, a sizable chunk of mod_perl first timers are looking to process arguments from a form, which can of course be done with CGI but having native libraries to handle this would be a big win. Make the perl glue libs readily available to the user with a standard mod_perl install.
Re: [RT] what's the roadmap?
Hi Joe, First, congrats and thanks for 2-2.07. Everything sounds great (well, maybe except for the words that may take some time doing ;-) My question: currently, there is one big libapreq2-2.07.tar.gz; Why don't we split it into two files, one for the C glue, a candidate for the integration into httpd (or apr/apr-util?), and the second, Perl glue, depnding on the former, a candidate for integration into mod_perl/CPAN? I believe that axing the Perl from the base library may clean the fears of the httpders, while having the C in httpd/apr and having only Perl in the Perl-glue (that depends on a standard stuff which was integrated into httpd/apr) may help the mod_perl guys to integrate it. -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [RT] what's the roadmap?
I think that's a good idea, so long as [EMAIL PROTECTED] can withstand the occasional question about our perl glue. Someday I'd actually like to see trunk/glue/perl moved over to mod_perl's trunk, and our C code folded into httpd somehow, but that may take some time doing. in principle I don't mind this idea, and we can certainly consider taking the perl glue under the mod_perl project. I guess the more difficult part would be in deciding how to package things so that it's the least complex for the end user. --Geoff
Re: [RT] what's the roadmap?
Eli Marmor [EMAIL PROTECTED] writes: Hi Joe, First, congrats and thanks for 2-2.07. Everything sounds great (well, maybe except for the words that may take some time doing ;-) My question: currently, there is one big libapreq2-2.07.tar.gz; Why don't we split it into two files, one for the C glue, a candidate for the integration into httpd (or apr/apr-util?), What makes the most sense to me is to somehow integrate trunk/include, trunk/library and trunk/module into httpd. For instance, I'd like to see an fcgi module grow up alongside trunk/module/apache2. I think splitting the library off into apr makes little sense from a user's standpoint, since the whole point of it is to parse server-side form submissions. and the second, Perl glue, depnding on the former, a candidate for integration into mod_perl/CPAN? Either directly into mod_perl, or as a standalone release from the perl pmc would be cool with me. -- Joe Schaefer
