[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Apache\Perl musings



-----BEGIN PGP SIGNED MESSAGE-----


I've started playing with my existing scripts to see what it takes to
convert them to be compatible with mod_perl.  Other than needing to add a
bunch of my()'s to solve the "compile once, run many" enviornment of
mod_perl, it doesn't look like a big deal.

Some things I'm turning on in on my Apache devel server are:
PerlTaintCheck (equiv. of -T)
PerlWarn (equiv. of -w)

I suggest we do the same on the prod/devel servers as well.

The only problem I have found that I can't figure out so far is why when I
edit the CGI, it doesn't work for the first few seconds (seems to be time
based).  I get an "Premature end of script headers" in the logs and on the
browser.  After about 2-4 seconds it starts working and continues to work
until I make another change.  And yes, I'm running `httpd -X` so that
there's only one httpd running (to get consistant results with mod_perl).
It does not appear to be based on the number of reloads.

One thing I haven't figured out is how useful my existing scripts will
really be.  I never planned any DB integration with the RHLUFAQ and a lot
of the fields will be different.  There's some good code there to do some
tricks (HTML'zing content, etc).  But a lot of the logic doesn't translate
to a DB environment (there's a lot of file tests to determine what
filename each entry gets).  Also, the administrator verification will be a
lot different.  It probably will be easier to start from scrach and
steal than to "port" the exisiting code. :-(

This brings up my next question regarding standardization.  What are
people's thoughts on writing forms?  Plain HTML or Perl/scripting?  HTML
means less processor load (though with mod_perl it's less of an issue).  
Perl gives a lot more functionality to the forms (allows you to vary the
form depending on how it was called, etc).  What about embed_perl which
allows you to embed perl code in a HTML document?

Personally, I prefer Perl due to the power it gives us.  And if one 1/8th
of what Dana/Roger says is true about getting extra systems is true, then
the system load is a non-issue.  I've never used Embed_Perl before, so I
can't comment on that too much execpt it sounds cool.

Also, what about embeding client scripting into pages to enhance their
funtionality?  I'm talking about JavaScript (not Java apps or ActiveX).  
While I can't think of any situtation where JS is necessary (and we should
*avoid* JS code that is "necessary" for the user), there are situations
where JS makes things easier on the user.

http://www.best.com/~aturner/RedHat-FAQ/CGI/editfaq.cgi

Gives an example of what I'm talking about.  (The buttons that open/close
another windows)   The good part about this is that if it doesn't work,
no big deal.  It wouldn't be a big deal to put some browser checks so that
the buttons only appear to compliant browsers either.

On another note, does anyone know how to force apache to write to the
access/error logs imediately, rather than caching the writes?  I haven't
found it in the FM yet.  Debuging is a pain when you have to wait 15
seconds to see what's written in the logs for each request.

Regards,
Aaron

- -- 
Aaron Turner           | Either which way, one half dozen or another. 
aturner@pobox.com      | Check out the Red Hat Linux User's FAQ Online!
www.pobox.com/~aturner | http://www.pobox.com/~aturner/RedHat-FAQ/
All emails from this account are PGP signed.  Lack of a signature is "bad".
PGP Key fingerprint = FB E1 CE ED 57 E4 AB 80  59 6E 60 BF 45 1B 20 E8



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNn2LSzM3jpXy1kJtAQFo2QP+LGA02tNEfC8uQFDZI1BmgS8LJC+OHYwF
CU3M3o+E/4AmcxSvRfmrRUcH6NFn68RldnUyS2GgSZhoV/ePUwRGyhjXZmENI8H8
TAAQo6nfNS6sxEUIYphuhhyRJ1iv5ra9kA1miZdi2pmZ8+gj/yk0vl4DVpUysS6V
r8f3imod+nw=
=OHXl
-----END PGP SIGNATURE-----