Re: [cgiapp] CAP::Apache and CAP::Session

2004-11-18 Thread Michael Peters
Cees Hek wrote: On Tue, 16 Nov 2004 17:10:08 -0500, Jesse Erlbaum [EMAIL PROTECTED] wrote: Performance benefits over Apache::Registry seem marginal when you consider the total request time (network transit, database access, etc.) OTOH, functionality takes a hit, as you are now seeing. Also, if

RE: [cgiapp] CAP::Apache and CAP::Session

2004-11-18 Thread Jesse Erlbaum
Hi Michael -- + speed - yes I know that in some circumstances CGI doesn't perform that badly under mod_perl since it doesn't need to be loaded again. I also know that a web application typically has other bottle necks besides parameter parsing and cookie generation (like database

Re: [cgiapp] CAP::Apache and CAP::Session

2004-11-18 Thread Drew Taylor
On Thu, 18 Nov 2004 16:30:22 -0500, Jesse Erlbaum [EMAIL PROTECTED] wrote: And one more thing: If you develop in API space, you probably have to restart Apache every time you make a change. Wouldn't it be infinitely easier to be able to start Apache in a development mode which causes Minor

RE: [cgiapp] CAP::Apache and CAP::Session

2004-11-16 Thread Jesse Erlbaum
Hi Cees -- OK, I'll switch it to use CGI::Cookie directly instead of using it through CGI.pm. I'll try and get this out soon, but patches are always welcome. Before you go and modify your module, shouldn't the responsibility for providing a working cookie() method be on CAP::Apache? I

Re: [cgiapp] CAP::Apache and CAP::Session

2004-11-16 Thread Cees Hek
Hi Jesse, Good to hear from you again. We've missed your input here in the last little while. On Tue, 16 Nov 2004 06:56:27 -0500, Jesse Erlbaum [EMAIL PROTECTED] wrote: Before you go and modify your module, shouldn't the responsibility for providing a working cookie() method be on

RE: [cgiapp] CAP::Apache and CAP::Session

2004-11-16 Thread Jesse Erlbaum
Hi Cees -- Good to hear from you again. We've missed your input here in the last little while. Lol... You guys seemed to have everything so well in hand, I didn't want to mess it up! The part I was planning to alter was the creation of a new cookie. This only currently uses $self-query

Re: [cgiapp] CAP::Apache and CAP::Session

2004-11-16 Thread Michael
Jesse Erlbaum wrote: The part I was planning to alter was the creation of a new cookie. This only currently uses $self-query since it is convenient, but it could easily use CGI::Cookie directly without breaking encapsulation. All that really needs to be done is for this to send a valid formated

Re: [cgiapp] CAP::Apache and CAP::Session

2004-11-16 Thread William McKee
On Tue, Nov 16, 2004 at 01:30:16PM -0500, Michael wrote: The main reason I didn't do this was because the CAP::Apache wasn't a wrapper around Apache::Request, but a plugin for C::A. I figured there was a reason for not subclassing... I think it would also be breaking encapsulation if my

RE: [cgiapp] CAP::Apache and CAP::Session

2004-11-16 Thread Jesse Erlbaum
Hi Michael -- The main reason I didn't do this was because the CAP::Apache wasn't a wrapper around Apache::Request, but a plugin for C::A. That's correct -- it's not a wrapper. But you're trying to cram an Apache::Request peg into a CGI.pm-shaped hole. As the IBM commercial goes, You're

Re: [cgiapp] CAP::Apache and CAP::Session

2004-11-16 Thread William McKee
On Tue, Nov 16, 2004 at 05:10:08PM -0500, Jesse Erlbaum wrote: I must ask: Why are you migrating in the first place? Mostly to experiment with using more of the mod_perl-style code. Performance benefits over Apache::Registry seem marginal when you consider the total request time (network

Re: [cgiapp] CAP::Apache and CAP::Session

2004-11-16 Thread Cees Hek
On Tue, 16 Nov 2004 17:10:08 -0500, Jesse Erlbaum [EMAIL PROTECTED] wrote: Performance benefits over Apache::Registry seem marginal when you consider the total request time (network transit, database access, etc.) OTOH, functionality takes a hit, as you are now seeing. Also, if the only part

Re: [cgiapp] CAP::Apache and CAP::Session

2004-11-11 Thread Michael
should just be this simple... Cees Hek wrote: On Wed, 10 Nov 2004 18:22:47 -0500, Michael [EMAIL PROTECTED] wrote: Well, my vote is for using header_add and CGI::Cookie, since that's what you are doing indirectly anyway, right? OK, I'll switch it to use CGI::Cookie directly instead of using it

[cgiapp] CAP::Apache and CAP::Session

2004-11-10 Thread Michael
Problem: I have upgraded an application to use CGI::Application::Plugin::Apache which, if you haven't seen changes you app to use Apache::* modules instead of CGI.pm. I also wanted to use the CGI::Application::Plugin::Session module as well since it's easy to use and clean. But it uses the

Re: [cgiapp] CAP::Apache and CAP::Session

2004-11-10 Thread Rhesa Rozendaal
Michael wrote: Problem: I have upgraded an application to use CGI::Application::Plugin::Apache which, if you haven't seen changes you app to use Apache::* modules instead of CGI.pm. I also wanted to use the CGI::Application::Plugin::Session module as well since it's easy to use and clean. But

Re: [cgiapp] CAP::Apache and CAP::Session

2004-11-10 Thread Cees Hek
On Wed, 10 Nov 2004 12:04:53 -0500, Michael [EMAIL PROTECTED] wrote: Problem: I have upgraded an application to use CGI::Application::Plugin::Apache which, if you haven't seen changes you app to use Apache::* modules instead of CGI.pm. I also wanted to use the

Re: [cgiapp] CAP::Apache and CAP::Session

2004-11-10 Thread Cees Hek
On Wed, 10 Nov 2004 18:22:47 -0500, Michael [EMAIL PROTECTED] wrote: Well, my vote is for using header_add and CGI::Cookie, since that's what you are doing indirectly anyway, right? OK, I'll switch it to use CGI::Cookie directly instead of using it through CGI.pm. I'll try and get this out