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

["Jesse Erlbaum" <suppressed>]

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 connections, 
> large queries, etc). Even knowing this, If all I'm doing is using the 
> Apache::* modules for dealing with parameters and cookies, 
> why not use 
> the solution that is faster.

If that's all you're doing, naturally, go for it.  The problem is when
you need some of those other features.


> You can always throw more hardware at it right? But if with a simple 
> decision to not use CGI.pm can be made and I can squeeze even just a 
> couple of drops more out of my app why wouldn't I? I don't think that 
> "it's not that much faster" is a valid argument in and of itself.

Not in and of itself.  But "it's not that much faster" becomes a highly
valid argument when you need features in CGI.pm, or your developers are
already very familiar with CGI.pm and you're on a schedule.  In that
circumstance, switching to an environment with a learning curve because
it is only very slightly faster (but much more geek chic) is a luxury.


> + size - CGI.pm is a very large module (as others have 
> pointed out just 
> recently) and by not using it at all I save myself memory. This again 
> would help in high performance situations.

Not as much as you think.  If you're pre-loading CGI.pm at Apache
startup, the memory is shared between child processes.


> + more access to apache - I agree that in most typical situations all 
> you do in a C::A is content generation. But I can think of other 
> situations where it would be nice to have a more direct access to the 
> apache API.

I can too.  That's why I'm a big advocate of writing Apache modules for
authentication and authorization, rather than putting it in your (CGI)
application code.

But the way I look at the architecture, Apache modules are in a layer
separate (and orthogonal) to the CGI application layer.  (The Apache
team also envisions it this way.  That is why there are separate request
phases in the first place.)  If you use mod_perl properly there is no
reason why you'd want to "make changes to the logging mechanism"
anywhere BUT during the logging phase -- IOW, far from your CGI
application request phase.

And the separation is more than architecturally.  It is staff-wise, as
well.  You can find more programmers familiar with CGI.pm than Apache's
API.  Apache-savvy developers, such as yourself, can write sophisticated
custom handlers, and more junior CGI developers can do all the heavy
lifting.  Unless your org likes to pay for all senior developers, most
orgs would prefer to have a small number of specialists, and a larger
number of (less expensive) developers for the day-to-day work.

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
your apps to run as CGIs, and then flip back to "production mode" to
gain mod_perl performance without having to change one line of code?
I've been doing exactly that for years by using CGI.pm +
Apache::Registry.

(Restarting Apache after every change is only slightly less irritating
than recompiling.  If I wanted to recompile all the time, I'd use Java.)


> I just think that it 
> hampers the adoption of C::A for some when becomes difficult 
> to use the 
> apache API.

Interesting point.  Maybe you're right, but I've had this conversation
many times over the years (here, and on the mod_perl mailing list), and
whenever I corner someone and ask them which features of the Apache API
they want at CGI-runtime, they come up blank.  Once they acknowledge
that things like logging, authentication, and authorization are better
handled as separate (non-CGI) modules, the main motivator for developing
directly in the Apache API becomes a matter of preference and a penchant
for the more fashionably cool bleeding edge.

Apache::Request has made it MUCH easier to develop in API space for non
API-savvy coders.  But if they're not API savvy, what are they doing
here, anyway!


TTYL,

-Jesse-


--

  Jesse Erlbaum
  The Erlbaum Group
  suppressed
  Phone: 212-684-6161
  Fax: 212-684-6226




---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed