Re: [cgiapp] Factoring out CGI.pm

[eric]

Jesse,

 The first case (which you reference in your message) can be factored out
 entirely using mod_perl.  By adding a simple startup.pl, CGI.pm can be
 pre-compiled on server start.  If your issue is limited to compile-time
 performance, using mod_perl will eliminate this as a significant factor.

A most excellent point!  Using mod_perl would definitely alleviate the startup
time costs.  However, there is also the size factor, and this is particularly a
big issue under mod_perl, since all modules will stay compiled and cached
within each Apache process.

Many will still choose to use CGI.pm under mod_perl, because it's the right
module for them.  However, as the following document within the mod_perl guide
points out:

 http://perl.apache.org/guide/performance.html#_Bloatware_modules

Loading Apache::Request adds around 48K to the size of each httpd process.
However, adding CGI (with everything compiled) takes up 1.8MB.  Eek!

On top of that, much of Apache::Request is written in C, so there may
definitely be some performance differences involved.  As an example:

 http://perl.apache.org/guide/performance.html#Apache_args_vs_Apache_Request

The mod_perl guide offers some benchmarks on a few modules, and they all turned
out to be at least twice as fast as CGI when running under mod_perl.

Knowing that, even though CGI.pm offers some wonderful functionality, many
mod_perl users try to stay away it.

 Once you eliminate technical considerations, such as compile-time
 performance, there are (IMHO) some compelling reasons to use CGI.pm.

I agree whole-heartedly!  CGI.pm offers an incredible amount of useful
features.  However, I don't feel that I'm necessarily saying, Lets get rid of
CGI from the picture.  The OpenPlugin Plugin Manager that I'm building
actually offers a CGI driver, allowing one to take full advantage of CGI if
they choose.  At the same time though -- OpenPlugin would allow them to switch
out the CGI driver, for the Apache::Request driver, at any time.  OpenPlugin
just offers a standard interface for CGI and Apache::Request (amongst other
things).

But, to be able to use OpenPlugin within CGI::Application -- even if we're
looking to use the CGI module -- CGI::Application would need to use
OpenPlugin's interface, in order to be capable later of changing drivers.

I am aware that there are a certain amount of issues that would be
encountered with an approach offering a choice in this matter.  I've been
tinkering around with the code in CGI::Application, just to see what it would
entail to produce what it is I'm hoping to able to utilize.

One particular difference is that we'd lose the benefit of loading CGI at
compile time, instead of runtime.  I'm not sure how big a deal this would be to
folks.

To fully be able to make use of factoring out CGI.pm, there are also some
design philosophy issues that may be encountered, although many of these can
end up being optional.

1. With the combination of modules that I'm putting together, I've seen a
desire in many to actually make CGI::Application capable of having a parent
class, which may be CGI, OpenPlugin, or whoever.  While useful, it also makes
me scratch my head -- would this break any OO design ideals?

2. Given #1 above, that breaks CGI::Application's 'param' method (as CGI,
Apache::Request, and OpenThought have param methods).. if allowing
CGI::Application to have a parent class is desired, then perhaps the name of
the param method needs to be an option.

3. There are times when one may need to output data to the browser, at several
points throughout the life of a CGI/mod_perl app.  What if we're about to do a
long database query?  For this, maybe we'd want to output occasional status
messages.  CGI::Application currently offers an excellent mechanism for keeping
code clean, by having you return, as a string, the HTML you want delivered to
the browser.  In a case where this behaviour may not be desired though, what
are the thoughts on being able to return undef, instead of HTML.  Perhaps undef
could signal CGI::Application that headers and HTML have already been sent.

These are all some thoughts.  I'm most curious to hear what everyone has to say
on the matter.  Are features like this something people want out of
CGI::Application?  Would what I'm suggesting be better off implemented in a new
module?  I'm also willing to put my code where my mouth is -- I'd be more then
happy to assist with any of the above :-)

Thanks for your time,
  -Eric

-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.vm.com/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[cgiapp] Survey creation software

[Brett Sanger]

I've bitten off a large project, and I'd love some advice.

I need to write survey creation and taking software analogous to Slices
[ http://www.electricvine.com/products/Overview.asp?ProductID=31 ] or
Pegasus [ http://www.websurveyor.com/prod_intro.asp ].

I'm claiming we're better off writing our own than buying theirs for two
reasons:
1) full control (I know my apps will survive a linux kernel upgrade, we
can fix our own bugs, we can add features on demand)
2) integration with our other applications, current and future

I've been given the chance to prove my claim, so now I need to write the
thing.

To keep this moderately on topic, here's my planned layout.  I'd love to
have comments and (in particular) to be informed of any CPAN modules that
will do parts of this for me:

First, an overview of what we've got:  Dynamic pages are perl CGIs running
CGI::App (or rather, a subclass with a few local functions added) and
pulling Template::Toolkit templates.  no mod_perl.  (Haven't needed the
speed, and we're too busy developing new apps to overhaul the
whole system without cause).  Linux system.

Here's my current plan: Survey creation script/module will step you
through the creation of a survey.  Just getting questions is easy, but I
need to allow for some layout directions, form validation, and branching
control (If you answered Yes, go to question 6).  The end result of
this, which steps through several pages, is an XML file that describes the
survey.  This would have to be able to save a survey and later modify it.

Survey taking script/module reads the XML file and displays the given
survey, collecting data through several pages.  Many people will doubtless
fail to complete the entire survey, and I want that data, so I'llhave to
have some method of savign session data to file.  I won't, however, be
allowing people to come back with a new session to complete their old
session.

Survey report script/module takes the answers for a given survey for a
given date range and returns an Excel spreadsheet.  I'll probably put some
really fundamental analysis there, but make the end user do anything
sophisticated on their end.

Judicious use of CGI::App should allow me to create subclasses for special
cases -- identity verification, extra analysis, etc.

So far I've identified and involved (beyond CGI::App):
HTML::FillInForm
Data::FormValidator
Spreadsheet::WriteExcel

Modules I'd like to have clues about:
XML-data structure translator (something more direct than XML::Parser)

Session data that I can fairly easily manipulate from outside sessions,
and not involving mod_perl.  CGI can save and load, but it appears to
overwrite itself, where I'd want to merge.

Comments?A



-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.vm.com/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [cgiapp] Factoring out CGI.pm

[Mark Stosberg]

On Fri, 3 May 2002 [EMAIL PROTECTED] wrote:

 3. There are times when one may need to output data to the browser, at several
 points throughout the life of a CGI/mod_perl app.  What if we're about to do a
 long database query?  For this, maybe we'd want to output occasional status
 messages.  CGI::Application currently offers an excellent mechanism for keeping
 code clean, by having you return, as a string, the HTML you want delivered to
 the browser.  In a case where this behaviour may not be desired though, what
 are the thoughts on being able to return undef, instead of HTML.  Perhaps undef
 could signal CGI::Application that headers and HTML have already been sent.

I ran into this particular issue when I wanted to return some unbuffered
output from within the CGI::App framework. The solution is easy enough:

1. Turn on unbuffered IO.
2. Send headers and output to the browser.
3. exit manually instead of returning.

To do that sort of thing most of the time would be to work against the
CGI::App system in my opinion. However, for the rare case where it's
desired, it's a more straightforward solution to me then learning some
new API to do something that's already easy.

  -mark

http://mark.stosberg.com/


-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.vm.com/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]