issues compiling the DBD::mysql
Title: issues compiling the DBD::mysql I'm having issues compiling the DBD::mysqlhopefully someone will have some insight. Box - mysql 4.0.14/perl 5.8.0/modperl1.28/apache1.38/DBI 1.37 At first installing via cpan or source would bomb during perl makefile without finding the mysql_config script. I installed mysql 4.0.14 via rpmmysql_config script didn't install; although it is working properly. So then I downloaded and untare mysql-standard-4.0.14-pc-linux-i686 and found the missing script in ../mysql-standard-4.0.14-pc-linux-i686/bin/mysql_config. After copying the script into my /usr/bin/ I find the make file gets created, but the make is bombing out with the following: Using DBI 1.37 installed in /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/auto Writing Makefile for DBD::mysql lamp:/home/jhodge/dloads/ap_mp/DBD-mysql-2.9002 # make cc -c -I/usr/local/lib/perl5/site_perl/5.8.0/i686-linux/auto/DBI -I -DPERL_Y2KW-DPERL_POLLUTE_MALLOC -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOU-D_FILE_OFFSET_BITS=64 -O3 -DVERSION=\2.9002\ -DXS_VERSION=\2.9002\ -fpic usr/local/lib/perl5/5.8.0/i686-linux/CORE dbdimp.c In file included from dbdimp.c:29: dbdimp.h:31: mysql.h: No such file or directory dbdimp.h:32: errmsg.h: No such file or directory make: *** [dbdimp.o] Error 1 lamp:/home/jhodge/dloads/ap_mp/DBD-mysql-2.9002 # perl Makefile.PL --cflags -I /bin/ -L /usr/lib/ I will use the following settings for compiling and testing: cflags (Users choice) = -I libs (Users choice) = /usr/lib/ nocatchstderr (default ) = 0 nofoundrows (default ) = 0 ssl (guessed ) = 0 testdb (default ) = test testhost (default ) = testpassword (default ) = testuser (default ) = To change these settings, see 'perl Makefile.PL --help' and 'perldoc INSTALL'. Unrecognized argument in LIBS ignored: '/usr/lib/' Using DBI 1.37 installed in /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/auto Writing Makefile for DBD::mysql lamp:/home/jhodge/dloads/ap_mp/DBD-mysql-2.9002 # make cc -c -I/usr/local/lib/perl5/site_perl/5.8.0/i686-linux/auto/DBI -I -DPERL_Y2KW-DPERL_POLLUTE_MALLOC -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOU-D_FILE_OFFSET_BITS=64 -O3 -DVERSION=\2.9002\ -DXS_VERSION=\2.9002\ -fpic usr/local/lib/perl5/5.8.0/i686-linux/CORE dbdimp.c In file included from dbdimp.c:29: dbdimp.h:31: mysql.h: No such file or directory dbdimp.h:32: errmsg.h: No such file or directory make: *** [dbdimp.o] Error 1 Does anybody have any suggestions? I'm also thinking of compileing the source from mysql-standard-4.0.14-pc-linux-i686 and try to re-build mysql first. Although mysql is running, so this might be the wrong thing to do thanks, JH
setting httpd for Apache::test
Title: setting httpd for Apache::test I have perl 5.8.0 with apache 1.3.28, and mod_perl 1.28 installed. I need the Apache::Test to be installed as well, as it is a req. for many other modules. I'm running into trouble with make test. Apparently it can't find the httpd server. How/Where would I add the path so that this mod will find the httpd server. Can I config the makefile or should this be set someplace else? tail make test /usr/local/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -clean *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -clean APACHE_USER= APACHE_GROUP= APACHE_PORT= APACHE= APXS= \ /usr/local/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -verbose=0 *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -verbose=0 !!! no test server configured, please specify an httpd or apxs or put either in your PATH. For example: t/TEST -httpd /path/to/bin/httpd make: *** [run_tests] Error 1 thanks, Jeff
which mod defines transferlogs?
Title: which mod defines transferlogs? first off. perl Makefile.PL -httpd /usr/local/apache2/bin/httpd Stas...this worked great for configuring httpd for Apache:: testI assumed it was something along those lines tks. second. While installing Apache::Bundle through cpan I'm getting this error (below) about transfer logs is not defined/ mod is missing. Which mod would this be? Also I tried installing libapreq from source, but the same error occurred. *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -verbose=0 *** root mode: changing the fs ownership to 'nobody' (65534:65533) /usr/sbin/httpd -X -d /root/.cpan/build/libapreq-1.2/t -f /root/.cpan/build/libapreq-1.2/t/conf/httpd.conf -DAPACHE1 using Apache/1.3.23 waiting for server to start: .Syntax error on line 28 of /root/.cpan/build/libapreq-1.2/t/conf/httpd.conf: Invalid command 'TransferLog', perhaps mis-spelled or defined by a module not included in the server configuration !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Error 143 /usr/bin/make test -- NOT OK Running make install tks, -jh
RE: the installation nightmare continues
Title: RE: the installation nightmare continues edit makepl_args.mod_perl: APACHE_SRC=../apache-1.3/src APACHE_PREFIX=/usr/local/apache DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 This is exactly what mine looks like. I don't have the: APACI_ARGS=--enable-module=rewrite APACI_ARGS=--enable-module=so since I doun't want to run modperl as DSO. Most literature I'm reading points against it...so for now I'm just trying to have modperl run static. I didn't relaize that do_httpd=1 was building apache...My issue still remains that make test still won't work. Here is the tail of my make test output: cp t/conf/mod_perl_srm.conf t/conf/srm.conf /home/jhodge/dloads/ap_mp/apache_1.3.28/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 Syntax error on line 3 of /home/jhodge/dloads/ap_mp/mod_perl-1.28/t/conf/httpd.conf: Invalid command '=pod', perhaps mis-spelled or defined by a module not included in the server configuration will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/local/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 111 It looks like apache isn't building properly through the modperl install What would cause? : Invalid command '=pod', perhaps mis-spelled or defined by a module not included in the server configuration It builds if I make apache without modperl
the installation nightmare continues
Title: the installation nightmare continues Taking a step or two back I have started the process over again. I have created my download directory for a non-root user and built and compiled perl 5.8.0, which went smoothly and passed all of the tests along the way. This brings me to mod_perl. I opted to build apache staticly, and use the makepl_args.mod_perl file that Ged (tks ged) had suggestion. Reading through the mod-perl install site (http://perl.apache.org/docs/1.0/guide/install.html), it actually made a lot more sense after the suggestion. I'm having issues running make test for mod perl. Since Apache is staticly built, it needs to be running in order to test mod perl. snipet make test fails You cannot run make test before you build Apache, so if you told perl Makefile.PL not to build the httpd executable, there is no httpd to run the test against. Go to the Apache source tree and run make, then return to the mod_perl source tree and continue with the server testing. /snippet So I built, tested and made apache with: $ ./configure --prefix=/usr/local/apache $ make $ make install $ usr/locall/apache/bin/apachectl start (started fine) Running make test for mod perl gives: server failed to start! please examine t/logs/error_log This looks like its apache test server is not working, but apache is tested. compiled, built and started. I ran into this error before I compiled apache, and it made sense why I was getting the error, but now that this is fixed it shouldn't be a problem. I'm I missing something? also I checked modperl/t/logs/error_log where mp test should write to (and says that it is), but there is no log file
RE: mod perl issues/ cpan won't make properly
Title: RE: mod perl issues/ cpan won't make properly First off...thanks for addressing my issues Here's how I installed mod_perl/apache: cd apache_1.3.28 ./configure --enable-module=so cd mod_perl_1.28 I don't like the look of that. Please send *exactly* what you did. Have you got the mod_perl directory inside the apache directory? Your directories should be somethign like this: /dloads/apache_mod_perl/apache_1.3.28/ /dloads/apache_mod_perl/mod_perl-1.28/ perl Makefile.PL APACHE_SRC= /dloads/apache_mod_perl/apache_1.3.28/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACHE_PREFIX=/usr/local/httpd_perl make make test make install My directories look exactly like that. First I went to the apache directory and ran the configure to enable DSO. Then I went to the modperl directory and compiled mod perl with the apache with options outlined above What is the user that's running this? Don't do the first three steps as root, only do the 'make install' as root: Ok. I'll recompile them as another user. How does root user affect things? (appears to be a perl issue still see below) % perl Makefile.PL APACHE_SRC= /dloads/apache_mod_perl/apache_1.3.28/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACHE_PREFIX=/usr/local/httpd_perl % make % make test % su Password: # make install # exit % That backslash on the first line is important. If you've done everything as root and if you have the mod_perl directory inside the apache one, then it's best to remove the directories and start again. So using Cpan I tried to install the Bundle::Apache...which bombs out Don't worry about it for now, you don't need it for your mod_perl Apache. I need Apache::request and DBD::mysql rsn, but I guess that is another issue all together...allthough I though it might be a sign that something else is fowl if they won't make. ALSO here is perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: [snip] ccversion='', gccversion='2.95.3 20010315 (SuSE)', [snip] gnulibc_version='2.2.5' [snip] Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Aug 2 2003 13:09:23 [snip] Looks like you compiled this Perl yourself using gcc 2.95.3 a couple of days ago, is that right? Did the Perl tests all pass OK? yes...seeing as I wasn't sure whether it passed everything...and the make all test wouldn't run again; then I repeated my build/install steps interesting. its failing a test; output: (I'm fairly sure this wasn't the result the other day): Failed 1 test script out of 667, 99.85% okay. ### Since not all tests were successful, you may want to run some of ### them individually and examine any diagnostic messages they produce. ### See the INSTALL document's section on make test. ### You have a good chance to get more information by running ### ./perl harness ### in the 't' directory since most (=80%) of the tests succeeded. ### You may have to set your dynamic library search path, ### LD_LIBRARY_PATH, to point to the build directory: ### setenv LD_LIBRARY_PATH `pwd`; cd t; ./perl harness ### LD_LIBRARY_PATH=`pwd`; export LD_LIBRARY_PATH; cd t; ./perl harness ### export LD_LIBRARY_PATH=`pwd`; cd t; ./perl harness ### for csh-style shells, like tcsh; or for traditional/modern ### Bourne-style shells, like bash, ksh, and zsh, respectively. u=2.73 s=0.72 cu=193.21 cs=19.29 scripts=667 tests=68585 make[2]: *** [_test_tty] Error 1 make[2]: Leaving directory `/dloads/perl/perl-5.8.0' make[1]: *** [_test] Error 2 make[1]: Leaving directory `/dloads/perl/perl-5.8.0' make: *** [test] Error 2 73, Ged. btw - what is 73? Thank you, Jeff
mod perl issues/ cpan won't make properly
Title: mod perl issues/ cpan won't make properly I'm having a lot of problems with installing mod_perl/apache/ properly. Also installing through CPAN is an issue with certian modules as well. Suse 8.0/ linux 2.4/perl5.8.0/mod_perl1.28Apache1.3.28/ Here's how I installed mod_perl/apache: cd apache_1.3.28 ./configure --enable-module=so cd mod_perl_1.28 perl Makefile.PL APACHE_SRC= /dloads/apache_mod_perl/apache_1.3.28/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACHE_PREFIX=/usr/local/httpd_perl make make test make install After mod_perl is installed with Apache, I went to start the apachetl. It won't start saying that it is missing some modules. Why won't it start after the installation? I tried to install the apache bundle to see if that would help. So using Cpan I tried to install the Bundle::Apache...which bombs out saying : Why won't CPAN install this bundle ...tail Running make test make[1]: Entering directory `/root/.cpan/build/libapreq-1.2/c' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.2/c' make[1]: Entering directory `/root/.cpan/build/libapreq-1.2/Request' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.2/Request' make[1]: Entering directory `/root/.cpan/build/libapreq-1.2/Cookie' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.2/Cookie' PERL_DL_NONLAZY=1 /usr/local/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/*t/*.t does not exist FAILED--1 test script could be run, alas--no output ever seen make: *** [test_dynamic] Error 2 /usr/bin/make test -- NOT OK Running make install make test had returned bad status, won't install without force ALSO here is perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.18-64gb-smp, archname=i686-linux uname='linux lamp 2.4.18-64gb-smp #1 smp wed mar 27 13:58:12 utc 2002 i686 unknown ' config_args='-Accflags=-DPERL_Y2KWARN -DPERL_POLLUTE_MALLOC -Dmksymlinks' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DPERL_Y2KWARN -DPERL_POLLUTE_MALLOC -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O3', cppflags='-DPERL_Y2KWARN -DPERL_POLLUTE_MALLOC -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.3 20010315 (SuSE)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.2.5' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Aug 2 2003 13:09:23 @INC: /usr/local/lib/perl5/5.8.0/i686-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .
Re: templating system opinions (axkit?)
- Original Message - From: Jean-Michel Hiver [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, July 24, 2003 1:46 PM First of all, it is an implementation of TAL. TAL is a very clever open specification for WYSIWYG-friendly templates written by the Zope people. Do you have a URL for further reading on TAL? Petal has an active community and a mailing list, Ditto - a URL would be interesting! Regards Jeff
Wierd ENV issues
Greetings,
I have a W2K box, running Win32 binary of Apache 1.3.27, and mod_perl 1.27_01.
Everything seems to be working fine (AFAIK) except for some strange
environment variable stuff going on. Here is what I'm experiencing:
- I have a PerlRequire C:/startup.pl line in my httpd.conf, which works
fine. I set some ENVs in there, one of them being $ENV{HTML_TEMPLATE_ROOT} to
use with the HTML::Template module.
- I have a standard CGI test page that does the following:
# Print out the contents of %ENV just for kicks
my @keys = keys(%ENV);
@keys = sort(@keys);
foreach my $temp (@keys) {
print($temp . = . $ENV{$temp} . \nBR);
} # end foreach loop
This CGI page prints out all of my ENVs in order, just like one would think,
and it includes the 'HTML_TEMPLATE_ROOT' as it should.
- I also have an equivalent mod_perl based page utilizing Apache::Registry
vice vanilla CGI. It contains the following:
# Get the Apache::Request object reference
my $r = shift;
# Print out $ENV{HTML_TEMPLATE_ROOT}
$r - print(HTML_TEMPLATE_ROOT = . $ENV{HTML_TEMPLATE_ROOT} . \nBR);
# Print out the entire %ENV hash
my @keys = keys(%ENV);
@keys = sort(@keys);
foreach my $temp (@keys) {
$r - print($temp . = . $ENV{$temp} . \nBR);
} # end foreach loop
This mod_perl based script also prints out everything fine, until I comment
out the line the only prints out the 'HTML_TEMPLATE_ROOT' ENV. When I comment
it out, all of the sudden, the %ENV hash dump doesn't have it anymore either.
And when I uncomment it, the %ENV hash dump magically has it again. I've even
included a count for the %ENV display dump and it even says 31 when I am
printing HTML_TEMPLATE_ROOT, and 30 when I'm not.
I still have that ENV defined in my startup.pl. I've made sure my browser is
not caching pages, and I've restarted Apache a zillion times, still the same
behavior. One thing to note is that even when I comment out that single print
line for the ENV in the mod_perl based script, the CGI based one still
displays 'HTML_TEMPLATE_ROOT' properly, irregardless of whether the mod_perl
one does or not. I really stumbled onto this from blind luck, but it seems to
me that something kind of screwy is happening inside mod_perl or Apache. Can
someone shed some light on this?
Thanks in advance,
- Jeff
Re: Server side programming PHP Vs CGI Vs modPerl
DM Hello All, DM We have a server running in a Linux machine, now we would like to DM present the data in a browser using HTML interface. Can anyone suggest me DM which is the best one (CGI or PHP or modperl) to develop for web DM programming and also their advantages and differences to choose them as DM the best Depends on your requirements, which are not very clearly stated. Here's my head-up: CGI - simple, slow, I wouldn't recommend under any circumstances PHP4 - simple, fast, easy to learn, not as fully featured language as Perl. easy to install, cookies, sessions etc all easy out-of-the box. only for dynamic web pages - dont use it for data processing. easy to share one Apache server, multiple developers MOD_PERL - complex, fast, difficult to master for non-Perl programmers. lots of folks have problems installing /building - try yourself. Perl is a more fully-featured language, more general purpose can share web / data-processing classes and code We use PHP for complex interactive websites. We use Perl for data-processing. We plan on building our next generation ASP websites using mod_perl so that we can share code/classes between data-processing and the interactive sites. We have build a suite of system admin tools using mod_perl - this was much harder than the PHP development, but we are pleased with the results. You should join the PHP lists and compare the questions with those asked here - gives you an idea about some of the differences in the communities. Also consider the number of PHP4 v MOD_PERL development resources available. From: Lee Goddard mod_perl, obviously: you posted to a mod_perl users' list. You might wish to have a look at the case-studies pages of http://perl.apache.org, as well as http://www.perl.org. As for PHP, it's not perl, so forget it :) Sometimes you just need a toothpick, rather than a swiss-army chainsaw! 8-) my $0.02 Regards Jeff
RE: When perl is not quite fast enough
-Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: 16 December 2002 13:22 To: [EMAIL PROTECTED] Subject: When perl is not quite fast enough While reading Mark Fowler excelent Perl Advent Calendar (http://www.perladvent.org/2002/) 6th entry: http://www.perladvent.org/2002/6th/, in the references section I've noticed a link to Nicolas Clark's notes from his YAPC::EU::2002 presentation, on how to make your perl code faster: http://www.ccl4.org/~nick/P/Fast_Enough/ Dear ModPerl Lister, I have two questions: 1) In this list, I have seen folks asking general Perlish questions told to take their discussions elsewhere, along with the useless recommendation that they browse lists.perl.org - I have done this several times and joined a few of the lists, but only ever found lists that were rather beginner. I have also lurked in some of the groups.yahoo.com pearly lists without finding the right level. - can folks name any specific useful intermediate/advanced Perl lists? i.e. Perl 4+ years in a commercial env 2) I have one common approach to speed improvement that is not mentioned at all, to do with symbol table manipulation for functions, that I would like to polish via a list discussion - is this list appropriate for a thread discussing Perlish performance in general? I would guess that symbol table fiddles might be risky in a mod_perlish env. TIA Jeff
RE: [OT]: In my Farthers House there are many mansions
-Original Message- From: Perrin Harkins [mailto:perrin;elem.com] Sent: 01 November 2002 18:43 To: Tony Bowden Cc: [EMAIL PROTECTED] Subject: Re: [O] Re: Yahoo is moving to PHP ?? Tony Bowden wrote: It sounds like you're saying that you should only use a subset of Perl as some programmers may not understand the other parts of it? That is what I'm saying. I'm aware that this is a controversial opinion in the Perl world. However, I think it's reasonable to know your audience and write for them. That's the good part of More Than One Way. The New York Times writes their articles for a certain reading level, and I do the same with my code. snip... - Perrin Have to agree 100% with Perrin - in my experience, refactoring for performance is often used as an excuse for 'rewrite in my style', and at this point, future maintainability is usually severly compromised. Someone decides to replace all foreach loops with map, because this is more advanced and kewl. Does anyone else here remember the COBOL construct ALTER GOTO? I knew a chap who styled himself 'Super Hot Software Systems', whose favourite thing was ALTER GOTO - he soon got told where to go to! Look it up - it's a nightmare. Another time, a contractor working for me complained bitterly about someone elses obtuse code and lack of comments - the other party said 'Why don't you scroll up?', which he did - lo and behold, about two pages of beautiful comment. Mmmm as he read the comments, from the top, the complainant highlighted each line [easier to read] and when he understood the point of it all, pressed Enter - not realising that this replaced two screens of comment with an empty line... ah ha! we finally figured out the answer to the song: 'Where have all the comments gone?' 8-)
RE: Yahoo is moving to PHP ??
-Original Message- From: Mithun Bhattacharya [mailto:inzoik;yahoo.com] Sent: 30 October 2002 09:17 To: [EMAIL PROTECTED] Subject: Re: Yahoo is moving to PHP ?? No it is not being removed but this could have been a very big thing for mod_perl. Can someone find out more details as to why PHP was preferred over mod_perl it cant be just on a whim. I might be biased but considering the fact that PHP and mod_perl were neck to neck the cons should have made up for any slipup in performance. err did you look at the same slides as me? in all performance tests, YSP(perl) performed better than PHP, with the exception of memory usage. and there is a slide explaining why not Perl - the main objection seemed to be: QUOTE There's More Than One Way To Do It so many different Perl styles everyone's code looks different problematic for development when many people working on single codebase /QUOTE While there were Pros/Cons for Perl and the other rejectees, there were no Pros/Cons for PHP unless you count the gotchas mentioned after four months of using PHP: QUOTE Shallow learning curve - very easy to get some pages up quickly But mixed app/presentation problematic - PHP code and HTML forever intertwined - coding conventions help *.inc for function and class libraries *.php for web pages (call functions, echo $vars) - use Smarty to enforce separation? The drawback of using a code in template system, is that your code and HTML output quickly become forever intertwined. This makes changing the appearance of your pages difficult. For example, if you check the user cookie and load user database data in the common-header moving around where you include this template will change where you retrieve the database information for the user, possibly breaking other parts of the page which rely on that data. http://www.clearsilver.net/docs/apples_to_oranges.hdf The implement twice problem - much offline processing done in Perl - example: tax/shipping calculation for Shopping PEAR != CPAN - installer doesn't work in PHP 4.2.x - repository smaller, less mature than CPAN Surprises for people used to coding Perl /QUOTE Interestingly our experience was/is similar - we chose PHP 2.5 years ago for the development of our dynamic ASP interactive pages, and Perl for all our data-processing and server management etc. Hindsight shows us that it was the right decision at the time - we gained an 18 month lead on the competition. After 2.5 years, the 'have to write everything twice' problem has lead us to plan a gradual migration from PHP to Perl. All our new pages and products are being developed in mod_perl. I wonder if they will consider a similar change? Unlikely give the number of developers and the disruption? There is one con for PHP that I disagree with - you don't have to mix your HTML and application logic - just as in Perl, you can separate them if you want to - we work extensively in PHP ordered hashes and isolate the formatting and HTML generation in a few included utility collections, making it easy to change the HTML we generate without changing any of the underlying business information. Regards Jeff
Re: [OT] Perl vs. PHP..... but where is mod_perl?
soapbox Ok, I've been watching the list for most of the day and watching bashing of PHP (which IMHO is idiotic and immature but again, JMHO). I have ALWAYS said, use the right tool for the right job. PHP has it's place. IMNSHO, it's place is web interfaces. It's GOOD at that. That's what it ORIGINALLY was designed for. Perl on the other hand was not ORIGINALLY designed for that (I REMEMBER. I used Perl 4 way back when. I REMEMBER (VAGUELY) the changes between the last 4.X and 5.0 and all the work I had to go through with it. :)). Perl was originally designed for text manipulation. IE PERL = Practical Extraction and Reporting Language. I started out with Perl and C. Then migrated to mod_perl about 2 years ago. At that time, PHP wasn't up to snuff IMHO for serious work. It is now. I now use both PHP AND PERL! IE I have 3 tools in my toolbox instead of 1. I use PHP for the front end web interface. I use mod_perl for the backend work. IE doing DB manipulations, text manips, sending out emails, etc. I also use straight perl scripts for the above when those actions need to happen via cron. And if I have to, I DO dip down into C for those times when I ABSOLUTELY need speed. I am VERY excited about mod_perl 2.0. I am looking forward to hopefully being able to use it with SOAP to create application servers that ARE EASY to work with/write. (Not like java IMHO :)). As far as security holes go, ALL languages have em. Just that more people use PHP than mod_perl. So it's security holes are more noticeable. ANYONE can write insecure apps in ANY language. /soapbox -- Jeff Stuart [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [OT] Perl vs. PHP..... but where is mod_perl?
soapbox Ok, I've been watching the list for most of the day and watching bashing of PHP (which IMHO is idiotic and immature but again, JMHO). I have ALWAYS said, use the right tool for the right job. PHP has it's place. IMNSHO, it's place is web interfaces. It's GOOD at that. That's what it ORIGINALLY was designed for. Perl on the other hand was not ORIGINALLY designed for that (I REMEMBER. I used Perl 4 way back when. I REMEMBER (VAGUELY) the changes between the last 4.X and 5.0 and all the work I had to go through with it. :)). Perl was originally designed for text manipulation. IE PERL = Practical Extraction and Reporting Language. I started out with Perl and C. Then migrated to mod_perl about 2 years ago. At that time, PHP wasn't up to snuff IMHO for serious work. It is now. I now use both PHP AND PERL! IE I have 3 tools in my toolbox instead of 1. I use PHP for the front end web interface. I use mod_perl for the backend work. IE doing DB manipulations, text manips, sending out emails, etc. I also use straight perl scripts for the above when those actions need to happen via cron. And if I have to, I DO dip down into C for those times when I ABSOLUTELY need speed. I am VERY excited about mod_perl 2.0. I am looking forward to hopefully being able to use it with SOAP to create application servers that ARE EASY to work with/write. (Not like java IMHO :)). As far as security holes go, ALL languages have em. Just that more people use PHP than mod_perl. So it's security holes are more noticeable. ANYONE can write insecure apps in ANY language. /soapbox -- Jeff Stuart [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
RE: [OT] Perl vs. PHP..... but where is mod_perl?
- I get The requested story: 19716 has not been published (set live) yet. when I visit http://www.newsfactor.com/perl/story/19716.html Do you think the lists comments upset someone? 8-)
modperl 1.27 blues
Hi, I recently ran into a problem which has puzzled me about Perl compilation and installation. I would appreciate some help in understanding this. I run Redhat 7.2, which comes with perl-5.6.0-17. I was able to compile and install 5.6.1 and 5.8.0 all seemingly without problems. However, I ran into problems when I tried to get mod_perl 1.27 working on my machine. It compiles but does not pass the tainting test when I use either the 5.6.1 or 5.8.0 that I compiled and installed myself. When I revert back to using 5.6.0, I am able to pass the mod_perl self tests. I would like to use a more current perl than 5.6.0. But try as I might, I keep getting stuck on failing the tainting test. Can someone explain to me what is happening and help me get past this? Is this a simple as file permission problem? I compile perl as a regular user and only run make install as root. This is most confusing. Thanks, Jeff
File Problems in Perl-Run?
We recently migrated to modPerl, but only the Perl-Run parser (not Apache::Registry) to maintain compatibility while I clean up the scripts. We are seeing an abnormal behavior when reading files, very randomly (maybe about 1 out of 20 times) only the first line of the file is read. The code looks something like: open (FILE, $path/$filename); lines = FILE; close FILE; The file contains about 50 lines with each line containing values separated by commas. Normally, this routine returns a 50 element array lines with all the lines in the file. But sometimes, it just returns a 1 element array with just the first line of the file. Very strange. The only thing I can think of is that the old server was FreeBSD and the new server is Linux. Not sure if they handle file I/O differently in a Perl environment but it seems for some reason the script things the end of file is after the first line sometimes. Any suggestions, ideas, would be greatly appreciated. Thanks!
Verifying Which Handler
Title: Message Can someone send me an example of a test Perl script that will display which Perl handler Apache is using - Apache::Registry or PerlRun. We just migrated our website to a new server that was initially setup to run Appache::Registry but we don't have time to cleanup the code so I change the configuration (at least thought I did) to PerlRun. However we are seeing random behavior whenrunning scripts on ourwebsite (the content of the page unexplainably changes sometimes) that seem to indicate variables are not being reset (ie, maybe we are still using the Apache::Registry handler) Another tipoff was when he had to go change all the exit commands in the Perl scripts to Apache::exit();
Need Porting Sanity Check
Title: Message I have a 'medium' traffic e-commerce site (about 30GB xfer a month). It is mostly written in Perl (about 40 scripts or 4,000 lines of code). We have had no problems with performance to date but in preparation for future growth (in addition to other changes to the site's scripts) I thought it would be a good idea to switch from CGI to Mod_Perl. I read all of Stas Bekman's Porting Guidelines and looked at my scripts.While Ihave a long programming history, I must admit I started cranking out the code (ina nice modular fashion) as soon as I grasped the basic of the language, ignoring things like the -w operator, use strict;, andonly used variable localization (my) in someof my subroutines. I have determined that as a result, I would have quite a bit of work to do to move to modPerl (using Apache::Registry) including: - avoid inner subrouting nesting problem by having all Perl scripts called by the webserver only executive code in included files (using require from a main script) - make all variables localized using 'my' and special variables using local (although my coding is sloppy from a localization standpoint, it is written so it doesn't even need global variables - all variables are passed through the subroutines properly even though I forgot to specifically localize them) - Make sure required files are reloaded after modification bysetting PerlInitHandler to Reload, Setting PerlSetVar ReloadAll Off, and then when I am developing including Apacher::Reload in the scripts I am working on, then taking it out when they go into production (this was the method that made the most sense to me.) - I actually didn't really understand the problem with testing from the shell and using CGI::Switch or CGI.pm - Use '^T = time' in the scripts that I test filetime to determine its age - Use 'open my $fh, $filename or die $!; wherever I open files to insure they get closed properly That's going to be A LOT of work and I have lots of other modifications to do. So then I get to his section titled 'Apache::PerlRun--a closer look' and come to find out that Apache:PerlRun is basically a nice compromise offering some (not all) of the performance benefits of mod_Perl while not forcing you to have to drastically clean up your code. So here is my strategy that I would like a sanity check from anyone on. Go through and quickly clean up my existing code by adding use strict andlocalizing all my variables (with 'my' and 'local' for special variables) and then run is under mod_Perl using the Apache::PerlRun. Write all my new code so that it will run under Apache::Registry and then when I have spare time (ya right) go work on porting the older code. On thing that is interesting is that even though I added the -w operator to the end of #!/usr/bin/perl in my scripts and added use stricts; I am not seeing the hundreds of error messages I should see in either error_log or suexec_log. Any ideas? Thanks.
Need Porting Sanity Check
Title: Message Excuse my typos, I just wanted to clarify I added 'use strict;' not 'use stricts;' to my code along with the -w operator(#!/usr/bin/perl -w) and I'm not seeing all the errors in my logs.
.cgi with ModPerl
Title: Message I am setting up a server so that all my scripts have .cgi extentions. It would be nice if I could just add some directives in the httpd.conf that will have all my virtual hosts use modPerl for any files with either a .pl or a .cgi extention. The reason I prefer this method is that I have a couple scripts that I load in my httpdocs directory (the site home page is a script) So this is what I did: Commented out: AddHandler cgi-script .cgi Added the following: IfModule mod_perl.c Files ~ (\.pl|\.cgi) SetHandler perl-script PerlHandler Apache::PerlRun Options +ExecCGI allow from all PerlSendHeader On /Files/IfModule What I found is that when I only had this code only outside of the VirtualHost configurations, my test script indicated .pl was running in modPerl but .cgi wasn't. I only could get .cgi to run in mod_Perl bycopying this code inside of each of the VirtualHost configurations. Obviously I'm not an Apache config expert but one thing that also struck me strange is that while this code clearly indicates how to handle .pl and .cgi file extentions, prior to adding this, I could not find anywhere in httpd.conf where it maps .cgi files in this same way. The only code I could find is AddHandler cgi-script .cgi but shouldn't there be some additional corresponding code like PerlHandler Appache::Mod_CGI, Options +ExecCGI, etc.?? Also, how does appache know which module to use for ScriptAlias directories? I left the ScriptAlias directives in for the cgi-bin director and didn't change them to just Alias directives and it works fine but I guess that means a filematch directive overrides a ScriptAlias directive? A bit confused. Anyway, is the above method for achieving what I want an acceptable and secure/safe way to handle it? Thanks
CGI.pm and PerlRun
Title: Message I am gradually moving to mod_Perl using Apache::PerlRun instead of Apache::Registry. I am also considering switching from cgi-lib.pl to CGI.pm however I hear CGI.pm takes longer to load. Will CGI.pm automatically be cached, thereby eliminating the performance hit, by handling the scripts with Apache::PerlRun or do I have to preload the modules at server startup using PerlModule CGI; If I preload, do I have to put a PerlModule CGI; within every VirtualHost directive or just once in the httpd.conf and it will apply to all virtualhosts. And finally if I want to run CGI.pm in CGI-LIB compatibility mode, do I have to use a startup file instead or can I say: PerlModule CGI qw(:cgi-lib); I'm guessing I have to put it in a startup file?? Thanks
RE: separating C from V in MVC
-Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: 13 June 2002 03:43 To: Fran Fabrizio; [EMAIL PROTECTED] Subject: Re: separating C from V in MVC 2. Does the first part of my code above even remotely resemble a Controller? Sort of. It does choose a view and it does parse some user input, but a controller is more than just a dispatcher. It would include some of the code that you're currently putting into your doDoctorActivity() sub. The idea is that the model objects represent just the data in your application (the nouns) and the controller understands how to translate user input into a series of method calls on the model objects to carry out the user's request. It's hard to give a good example that is short, but let's say you were building an application to sell concert tickets. The act of buying the ticket might involve model objects representing a concert, a user, a form of payment, etc. The concert object knows how to reserve a specific seat (or call a seat object to do that). The payment object knows how to verify and charge a credit card. The user object has a mailing address. The controller knows how to turn the user's form data into a bunch of method calls on these objects that accomplish reserving the ticket and charging the user. If you find yourself writing a BuyTicket module, that's a controller not a model object. I disagree with this definition of a Controller. A Controller is primarily responsible for mapping user input onto a business Model, and should not know that buying a ticket requires creation of concert, payment, seat, client, theatre, agent, reservation, whatever objects. In the same way that the View keeps the output format independent of the Model properties, the Controller keeps the User Input method independent of business logic. This is the reason for having a Controller class. Consider that your mod_perl website Controllers will have to understand all about web requests, headers, error headers, cookies, sessions, redirects, URLs and URL decoding etc etc - these are things that relate directly to how the user is interacting with the Model. In the concert example, the Controller would interpret the web request, create a Ticket object, and call $Ticket-buy( %all_the_cleaned_up_params ). It would then pass this to the View to render. That's it. Consider the case where you wanted to buy hundreds or even thousands of tickets in a batch process - maybe you have agents that collect all the details for Kylie concerts, and then send them to you in a file. If you had made the mistake of creating a web Controller aka BuyTicket() module that understood it had to create concert, payment, seat, client, theatre, agent, reservation, whatever objects, you would have to duplicate all this logic AGAIN in the batch process Controller. You now have to maintain the business logic in two places. Always keep the _business_ behaviour in Models. The $Ticket-buy() processing must instantiate and create relationships to all the other objects it needs. Put all things that are specific to handling the User Interaction (eg web request) into your Controller. Business logic always goes into a Model. The idea is that the model objects represent just the data in your application (the nouns) and the controller understands how to translate user input into a series of method calls on the model objects to carry out the user's request. Models are not just collections of stateful data, they are the right place to encapsulate complex business behaviour. At the risk of repetition, all behaviour [e.g. $Ticket-buy()] that is not specific to the User Interface should go into Models. Controller and View are closely related elements of GUI. This is like the old 'Two Tier App' problem... when business logic and GUI become inexorably entwined, maintenance goes out the window. Have a look at this picture: http://www.ddj.com/documents/s=867/ddj0105i/0105if2.htm which comes from this article: http://www.ddj.com/documents/s=867/ddj0105i/0105i.htm Maybe in the future, we will get drag-and-drop via the web - interpreting this should go into the Controller. Maybe in the future you will change the business requirements for buying Tickets - this will go in a Model, and the effect will be felt consistently in both your web applications and your batch processing. Regards Jeff
RE: separating C from V in MVC
-Original Message- From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] Sent: 13 June 2002 13:23 To: Jeff AA Cc: [EMAIL PROTECTED] Subject: RE: separating C from V in MVC Controller: --- my $Stale = Model::WatchCollection-new( status = 'stale' ); Controller: --- my $WC= Model::WatchCollection-new(); Out of these two, I would think that the first one is actually better. What if you have 300,000 watches and only 25 are stale, for example (numbers that are not all that far from the truth, in my Don't make the mistake of fetching all the data when a Collection is instantiated. It is usually better to make the Collection only really fetch data when a View actually asks for it by calling $WC-fetch( status = 'stale' ), after all, sometimes you might go down another route and the View might never call fetch() - for example if there is an exception and you decide not to bother showing stale Watches. Also, you should generally not fetch everything from the database unless there is a very good reason to do so. Try to keep your memory usage to a minimum, and restrict the result set to something useful. I recall a system that used to pop up a dialog saying 'Warning: This will return 645,345 rows' and the only user option was 'Ok'! I have seen about 4.2 million Collection designs, and my current favourite is an abstraction of the Borland Data Engine DB/Table/Dataset design (BDE) in conjunction with some of the Java collection concepts. Common Collection niceties include things like 'find me Watch ABC' in the Collection. A Collection can have the concept of a 'current' thing so that a View can display both the list of Watches in a table, and more detailed attributes of the 'currently selected' Watch object etc. If you are going to support paginated collections, you should build this into your base Collection class. So far we have been talking about flat Collections, don't forget that some of them are not flat, but hierarchical - e.g. tree-like, and some are circular e.g. no beginning and no end, etc. ciao Jeff
RE: mod_perl/passing session information (MVC related, maybe...)
From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: 12 June 2002 15:11 You can store anything in Apache::Session; it's just a persistent hash table. However, storing query results based on a user's session is not a good idea! What if your users open up two browser windows and tries to do a search in each one? Server-side session data is global to all browser windows, so they'll get bizarre and incorrect results. Agreed, but he wasn't talking about storing the results, just the query parameters and current offset / number of rows, which is a-ok for putting into a session. some query session do's and don'ts... Don't forget that you can have multiple sessions - store the query params in a session identified by a query_id so that subsequent requests just say something like: A HREF='/searchquery_id=123456789action=next'Next/A Don't mix transient query sessions with a User Session that stores info about the user's logged in state etc. It would be normal for one user to have multiple queries in a login session Don't bother passing the query ids in cookies, they are not browser session specific. Just use the query_id as a parameter in the first/next/prev/last links as exampled above. You can then have a web control page that handles multiple queries simultaneously Do put the user_id into the query session and check it against the user_id in the User session to prevent query hijack My suggestions would be to have a separate cache just for query results. Or even to use a database that has a decent approach to caching. MySQL promises automatic cacheable paged queries in the near future. And if you write your own DB cache, you then need to manage the DB / cache synch issues, cache size, cache expiry etc etc issues. Good cache is very hard to do! better to get it from a real data bank. From: Vuillemot, Ward W [mailto:[EMAIL PROTECTED]] Sent: 12 June 2002 14:58 I want to be able to remember the last query so that I can return results into multple pages along with memory of where in the stack I am at. The easiest would to be store the query parameters along with the count information. . .but I do not want to use Apache::Session as I believe that has too much overhead for this sort of thing. Apache::Session is just what you want here! It is an easy peasy way to remember things on the server, and you can implement it with whatever type of storage underneath that you want [e.g. database] so that you can even share sessions when your query is being served by multiple web servers. If you look through the source, you will see that the overhead is minimal. You can specialise the session persistence mechanism if you want to for example store the key = value pairs as visible records in the DB rather than a serialised blob. Regards Jeff
RE: mod_perl/passing session information (MVC related, maybe...)
From: Ken Y. Clark [mailto:[EMAIL PROTECTED]] Sent: 12 June 2002 15:39 I've munged the query results in Perl and a couple template packages to make each link contain everything necessary to perform the query again (including every parameter from the original request) and putting in the appropriate limit_start number... Using sessions and a query_id is a shortcut for this, instead of stating all the complex parameters again, you just issue an id and put that into the link. An advantage of the session/id is that you end up with stateful query instances, and can remember [at least for a short period!] the total number of items, so that you can say 'Results 1 to 10 of 34,566' without having to count all results every time. This is also useful if you want users to be able to jump to a LAST page, as you can for example calc the starting point for limit statement easily. One disadvantage is that you cannot link to the query result pages, as you will no doubt expire the query sessions eventually. By putting all the params in the link, Ken's way lets the users link to the results, remember them in their favourites etc. Another possible feature is to allow the link to override any of the current query parameters, so to do a DB resort, you can say something like A HREF=/query?query_id=12345order=colourSort by Colour/A and the order param is not lost in amongst lots of other params. Obviously changes to the where clause, ordering etc may invalidate current row / page remembered values. Further variations are readily available. You can create persistent queries, rather than session queries, store the params in the DB and let your users have their very own private or shareable searches. If you use the optional param overide approach, you can store the params once, and then the options as a separate query that refers to the underlying query. When users add columns or other bits to the underlying, all child searches will respect the change. Regards Jeff
RE: mod_perl/passing session information (MVC related, maybe...)
From: Eric Frazier [mailto:[EMAIL PROTECTED]] Sent: 12 June 2002 16:52 I don't know this term query hijack can you put it in different words? Lets say your user who is the boss makes a query 'show me everyone's salary' and your system checks who he is, and because he is the boss, allocates query_id 1, issues the query and sends back page one with everyone's salary details. now some other user in the system can now say /query?query_id=1 and hijack the query results - i.e. they will see the results of the query, even though they should not be allowed to. If your security model is user centric, at a minimum you should put the user_id inside the query_id session, and only let the same user get the results from the saved query parameters. A better approach is to have the query ALWAYS authenticate the current user, then you won't ever give out data to the wrong person, and users can share query links that will work if they have the appropriate rights. from www.dictionary.com/searchq=hijack hijack n : seizure of a vehicle in transit either to rob it or divert it to an alternate destination [syn: highjack] v : take arbitrarily or by force; The Cubans commandeered the plane and flew it to Miami [syn: commandeer, highjack, pirate, expropriate] Regards Jeff
RE: mod_perl/passing session information (MVC related, maybe...)
From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: 12 June 2002 16:29 Agreed, but he wasn't talking about storing the results, just the query parameters and current offset / number of rows, which is a-ok for putting into a session. No, that's exactly what ISN'T okay for putting into a session. If a user opens two browser windows, does a search in each, and then pages forward in each set of results, he will get completely wrong pages if you do this. The query parameters from the first search will be written over and lost. Please - s/session/Apache::Session/g above You could do that, with a unique ID for each set of parameters, but you might as well just put the parameters right in the link unless they're very long. The [Apache::]session approach makes it easy to store and change lots of params to the query. It also lets you keep track of [recommendedly] minimal info about the Query on the server, without having to re-execute it, and it lets you pick up a previous query, with minor tweaks things like /query?query_id=12345order=value+desc where the tweak doesn't get lost in the params. Don't mix transient query sessions with a User Session that stores info about the user's logged in state etc. It would be normal for one user to have multiple queries in a login session Hold on, I think we actually agree, but you're using the word session for a bunch of different things. What you're saying here sounds like the opposite of what you said above. In common usage, a session is the state of the user's interaction with the application. A cache of query data would be something else. Again, please s/session/Apache::Session/g MySQL is fast, but usually not as fast as simple disk access. Cache::Cache and Cache::Mmap handle the details of the cache stuff for you, making it pretty easy. RANT I do agree that disk access _can_ be faster, but disagree with the implication that caching DB results outside the db is a cool trick. I would assert that in all general circumstances caching DB results is a Common Mistake. Special circumstances do exist, but in my experience very rarely, and that's why we have MI6. I can imagine a circumstance where a cache may prove useful - a large number of concurrent users, all wanting exactly the same data, slow db connection, non-optimisable query. This doesn't seem to be the case here where the question was about a faster Apache::Session. Interestingly MySQL and other DBs are often as fast as simple disk access - contrary to popular wisdom, most DB engines actually cache in memory, with more data access information and hence effective cache memory usage than is available to external cache components. Yes, Network transference can be an issue - but hey! be a masochist, buy a switch! I recall an impressive chap at a bank, who was asked to address performance issues. He immediately identified DB queries as taking far too long, and proceeded to hand craft a mega-smart shareable multi-user in-memory cache server in C. He ran into dozens of issues, which were ingeniously solved using the tersest possible sin tax. After about six months of effort, the performance problem still existed, - the DB resided entirely in memory anyway! A tweak of the schema [i.e. about 2 hours including test and release] by a DB admin took the problematic process from 2 hours down to 120 seconds. We spent cash for cache, and lived to rue the day. I parse 'use a cache for db stuff' as 'my XYZ cache component is way smarter than all the guys at 'Oracle|Sybase|MySQL' combined', or 'I know my data better than the database, cos I'm a kewl Koder'. Actually, I really parse 'use a cache for db stuff' as 'I don't really understand databases, 3NF and indexing, and can't be bothered learning to use them well'. /RANT But ok then, use a cache for your mod_perl query parameters, but don't call it an [Apache::]Session. 8-)
RE: separating C from V in MVC
From: Fran Fabrizio [mailto:[EMAIL PROTECTED]]
Sent: 12 June 2002 21:48
Nothing indepth, just a quick response, but it looks like your huge if
statement can be replaced using a hash. Maybe something like:
# just an eg, this data is static and can be required from
# your startup.pl so that all child get a shared copy
%global::dispatch = (
summary = { template = 'summary', actions = [ 'doSummary',
'doOther' ] },
doctor = { template = 'docact, actions = [ 'healthyself', ] },
)
# In your generic Controller / Handler
if ( exists $global::dispatch{$template} ) {
my $dispatch = $global::dispatch{$template};
my $tmpl = getTemplate( $despatch-{template} );
foreach my $function ( @{$dispatch-{actions} ) {
$function($dbh,$tmpl);
}
print header . %tmpl-output();
} else {
unavailable();
}
The nice thing about this is you end up with a generic Controller, and
can separate the config off somewhere else. The Controller will probably
change much less than your config, so separation makes sense.
I don't really see an issue with the Controller being responsible for
returning the response, after all it fielded the request in the first
place. I would try hard to keep ALL HTML in the View world - whether you
create a View class or use a templating approach.
0.02c
Regards
Jeff
RE: separating C from V in MVC
From: Rob Nagler [mailto:[EMAIL PROTECTED]] Sent: 10 June 2002 20:41 ... a Facade is the front face of the web site which includes colors, text, URLs, etc. All the other MVC components talk to the currently selected Facade when they need these values. The controller calls Bivio::UI::Task-parse_uri, which strips the *facade from the URL (if there) and sets the facade before parsing the rest of the URL. The default Facade is www.bivio.biz, which is why we don't need a rewrite. The links are generated by the Facade component Bivio::UI::Task. Sounds interesting, can you briefly describe the MVCF parts, and what their responsibilities are? Have you split the View into View + Facade? What are the differences between your MVCF and the MVP pattern? This allows the Facade to pick its own URLs. ... URLs are part of your user interface, not your controller. I think I like this, though the w3 might not 8-) We rarely change the controller except to add new function. Query and form values are parsed by the Models after they are translated to key/value format by the controller. I definitely like this - small number of relatively generic Controllers seems to me to be a desirable goal of an MVC arch. abstracted the concept of paging and drill down in our ListModel and Table classes. I find that the mix of business object e.g. Bank Account and presentation objects, e.g. Table can lead to confusion - are your Table objects just a way of organising data, or do they contain presentation style hints -e.g. dynamic width indication etc? Do you have something similar to a Bank Account object with some primary properties and containing a collection of current Transaction objects? Or do you focus on the presentation style objects - Tables, nested Tables, Lists etc? I looked over your site and code, compact and impressive - probably a stupid question, but are there any higher-level overviews of your approach / framework? TIA Jeff
The T in MVC?
I have some questions for users of Templating... we currently, (in another language) have a set of standard functions for things like printing data tables, so in our HTML page outlines, we just insert a call to printDataTable( table = $table, user = $user, data = $data, layout = layout ); parameters: * $table = optional ref to hash containing table title, any unusual table properties etc. * $user = ref to hash of user preferences * $data = ref to array of hash * $layout = ref to array of field names This standard routine combines these details and produces an HTML table containing the data. The use of standard routines ensures consistency throughout the entire site. Our printDataTable() function references site specific configuration data so that all the tables within a website are consistent, but that different sites can have their own skins applied. How is something like this best accomplished with the templating tools like TT? I guess I am asking how the template world achieves intra/extra site reuse and ensures consistency? Tia Jeff
Exceptional MVC handling (was something about MVC soup)
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
Sent: 07 June 2002 18:05
For example, if you have a form for registering as a user which has
multiple fields, you want to be able to tell them everything that was
wrong with their input (zip code invalid, phone number invalid, etc.),
not just the first thing you encountered.
Putting that into a model object is awkward, since coding your
constructor or setter methods to keep going after they've found the
first error feels wrong. You can write a special validate_input()
method for it which takes all the input and checks it at once
returning
a list of errors. You could also just punt and push this out to the
controller. (Not very pure but simple to implement.) Either way
you
can use one of the convenient form validation packages on CPAN.
When collecting multiple values for a single model, there generally is
both individual field validation, and an overall validation check. I
work in financial applications - often, there are inter-field
dependencies where validity cannot be determined until some decision has
been made, or some other detail gathered. As a general rule, there will
_always_ be a point in time after all details have been gathered, where
the Model must ask itself, 'Am I complete and integral?'.
What I am saying, is that you can't get around it! At some point in
time, you have to ask 'Are you OK, honey?'
There are a number of obvious stategies for dealing with this.
Some folks like to pass it all to the constructor, and get it over with
during the pangs of birth. Sometimes when this happens, instantiation
will fail, and you end up hanging your error information at a class
level ala DBD/DBI. Others don't mind instantiating an invalid Model, to
hold details of what went wrong (argh!). Some smarties pass an Exception
object into the instantiation, that collects all the exceptional detail
on the way, leaving the Controller at least with an instance handle on
what when badly wrong.
An alternative approach is to instantiate a mini-me Model without much
going on, and then to iterate through assigning properties or calling
methods and reaping any exceptions along the way into a collection for
later user castigation. Such mini-me Modellers must always remember to
ask the 'Was that good for you, Honey?' question at the end, or they end
up in purgetory, and have to bring home flowers!
Another intereting introspection is: Should I let the default View deal
with the errors, or should I have an Error View?
And the answer is... well, I guess it depends on your bent.
For finicky field errors, it feels natural that the default View should
indicate problems where they occurred [ala stars next to the required
fields, or little digs at the users, next to the offending erroneous
zone.
For major whamoo! if ( not defined $universe ) big bangs, it may be
better to redirect to a safer plane. If this is the case, the Controller
must be able to grok the exception and redirect as appropriate.
All in all, I think prefer a Controller something like this:
my $Exeption = My::Exception-new();
my $params = cleanupParams( $r );
my $Model = My::Model-new( %$params, exception = $Exception, );
my $View;
if ( $Exception-had_Fatal() or not defined $Model ) {
$View = My::ErrorView-new( exception = $Exception, model = $Model
);
} else {
$View = My::View-new( exception = $Exception, model = $Model );
}
print $View if $View;
print STDERR $Exception if $Exception-had_Any();
£0.04,
Regards
Jeff
RE: [OT] MVC soup (was: separating C from V in MVC)
From: Bill Moseley [mailto:[EMAIL PROTECTED]] Sent: 08 June 2002 20:48 I've gone full circle on handling user input. I used to try to abstract CGI input data into some type of request object that was then passed onto the models. But then the code to create the request object ended up needing to know too much about the model. For example, say for a database query the controller can see that there's a query parameter and thus knows to pass the request to the code that knows how to query the database. That code passes back a results object which then the controller can look at to decide if it should display the results, a no results page and/or the query form again. So in pseudo code-speak, how about something like: # Note that I am ignoring Exceptions for the sake of dealing with the # Controller / Model interaction question. # $param is a ref to an Apache::Table that contains all the user submitted # parameters from the request. The main job of cleanupParams() is to do # things like URDDecode() etc, and marshal all the user input into a simple # structure. my $param = cleanupParams($r); # Instantiate Model. Pass it ALL user parameters - Model can cherry pick only # the ones it is interested in, and ignore the others. Adding new parameters # in the preceeding View that gave rise to this request makes no difference # to the Controller - only the Model and View needed to change. my $Model = My::Model-new( %$param ); # And which View should we instantiate? Well, you might choose one in the # Controller, but I only do this if there was a major Model meltdown. For # no result searches, the usual search View should be able to handle things # with a nice message. Now, what happens is that features are added to the query code. Let's say we get a brilliant idea that search results should be shown a page at a time (or did Amazon patent that?). So now we want to pass in the query, starting result, and the page size. As shown above, the Controller doesn't really care about any new parameters, it passes them all, including new ones through transparently to the model. The model I like for paginated results is straight-forward. When the Model is instantiated, it does NOT find a query_id field in the passed parameters, so it assumes a brand new query, and returns the first N results. A brand new, unique query_id is issued, and becomes a property of the Model. In the paginated View, this query_id is inserted into a hidden field (or cookied if you prefer). A session is created using the query_id that contains all of the parameters that the Model considers important. The paginated View contains First, Last, Next, Prev links that just call the same URL with an action=next, last, prev etc. When the Model is instantiated for a subsequent page, it sees a query_id, loads all the query details in from the session storage, and retrieves the appropriate set of records for the this-time-round View. What I didn't like about this is I then had to adjust the so-called controller code that decoded the user input for my request object to include these new features. But really that data was of only interest to the model. So a change in the model forced a change in the controller. I think covered above? So now I just have been passing in an object which has a param() method (which, lately I've been using a CGI object instead of an Apache::Request) so the model can have full access to all the user input. It bugs me a bit because it feels like the model now has intimate access to the user input. I don't like this either, but probably need a concrete example of exactly what Request properties you find it necessary to use in your Model. The way I see it is that the Controller is interested in the gory details of the Request object, after all it is a Web Controller, but the Model should only be interested in the parameters. The Controller uses the Request object context, and sometimes basic parameters to decide which Model to instantiate, it doesn't care about Model parameter requirements - the Model must validate itself. links back to a page, such as a link for page next. I like to build links in the view, keeping the HTML out of the model if possible. But for something like a page next link that might contain a bunch of parameters it would seem best to build href in the model that knows about all those parameters. As described above, I like to use a session to store Model state over multiple executions / pagination of a collection type Model. Regards Jeff
RE: [OT] MVC soup (was: separating C from V in MVC)
From: Jesse Erlbaum [mailto:[EMAIL PROTECTED]] Sent: 06 June 2002 19:34 To: 'Bill Moseley'; [EMAIL PROTECTED] First off, it is less of an MVC crime to combine your Model and Controller than it is to combine your Controller and View. I disagree - coupling Controller and Model contradicts the fundamental tenet of MVC which is separation of Model from the Controller and View UIs. As I understand it, the main benefit of MCV is that the Model knows the minimal possible about the Controller and View UIs. Most pundits indicate that the only relationship between a Model and View is that of the weakly typed observer pattern. I should point out that the mod_perlish MVC as described so far in these threads is only loosely based on the MVC pattern, which was originally designed for more traditional stateful user interfaces than web browsing. Here are some MVC pages that indicate Models should NOT be closely linked to Controller, and that in fact the relationship between the two user interface components [ie Controller and View] may be stronger. http://ootips.org/mvc-pattern.html And the MVC relationships are covered, esp on page 5 of this http://www.cs.indiana.edu/~cbaray/projects/mvc.html and there are some good pictures on this link http://www.object-arts.com/EducationCentre/Overviews/MVC.htm which also says: 'What we really want, though, is a tight coupling between AM and View but a loose coupling between Domain Model and View' I parse this as 'tight coupling between Controller and View but a loose coupling between Model and View' £0.02 Regards Jeff
OT: MVC alphabet soup (= MVP?)
and so my research into the world of MCV continues, and suddenly I feel cheated when I discover that the MVC world moved on years ago to something brighter, shinier and newer? MVP - Model-View-Presenter So for us poor folks lagging behind, do any of the MVC pundits have any comments on Model-Vew-Presenter? My uninformed reading leads me to the following intermediate conclusions: The best explanation [and it covers MVC] that I have found seems to be ftp://www6.software.ibm.com/software/developer/library/mvp.pdf It appears to me that the MVC we are discussing in mod_perl is a simplification of the original - an almost stateless remote user interface is somewhat different from the richly interactive GUI apps that MVC was originally designed for. I would guess that there is no need for Views to register as observers with the Models [is there??] etc. Interestingly, most of the limitations of MVC that led to MVP seem to have to do with the interaction of Controller and View, which led to additional intermediate components that IBM call Interactors. Additional formalisations include the addition of Command components with do, undo and redo methods to communicate between the Controller aka Presenter and the Model, and Selection components to identify ranges and selections of data in the Model to be acted upon. All in all, the additions that led to MVP do not seem particularly applicable to web development - it seems to me that a simplified MVC may work better here. Do others concur? Does anyone know of an MVC disseratation similar to the IBM MVP document, that particularly discussed MVC in a web development context?
RE: [OT] MVC soup (was: separating C from V in MVC)
From: Bill Moseley [mailto:[EMAIL PROTECTED]] Sent: 06 June 2002 19:06 To: [EMAIL PROTECTED] My MVC efforts often fall apart in the C an M separation. My M parts end up knowing too much about each other -- typically because of error conditions e.g. data that's passed to an M that does not validate. And I don't want to validate too much data in the C as the C ends up doing M's work. This sounds like an interesting area to explore - I would quite like to get down to some specifics, for example to work through some concrete examples and bounce some designs around. Can we take a real instance where you have a problem, and see if we can develop an understanding? Will you be willing to post some descriptions of [possibly simplified] cases where you want to review your current MVC split? Or should we take a simple example and see what happens? For example, we could model a basic internet banking site - the data strunctures, range of events, presentation etc are simple and generally well understood. We can take the discussion off-line if the list feels it will be too OT. Regards Jeff
RE: MVC alphabet soup (= MVP?)
From: Jesse Erlbaum [mailto:[EMAIL PROTECTED]] Sent: 06 June 2002 23:21 To: 'Jeff'; [EMAIL PROTECTED] All in all, the additions that led to MVP do not seem particularly applicable to web development - it seems to me that a simplified MVC may work better here. Do others concur? YES! I would agree whole-heartedly. As I said in my first message on this thread, a pattern is not a panacea. Practical, useful solutions are rarely academically correct. Let's not get caught up in pattern-for-pattern's sake thinking here. If an aspect of someone else's idea (and that's all patterns like MVC are -- someone else's idea!), then TOSS IT! Jettison. Use what works and throw out the rest. Jesse, I see your assertions, and may agree with them, but I am interested to know specifically WHY you think MVC might be more appropriate than MVP, and what parts of MVP are actually [!]cool-for-web concepts. Call me old fashioned, but when I see that a large community of folks have obviously invested much thought and effort into the original Smalltalk MVC and then into MVP. I am reluctant to throw out the baby until I am sure that the water is cold! I too like a 'use what works' approach, but tempered with a bit of 'softly slowly lookee feelee', especially when it comes to fundamental design and approach 8-) Regards Jeff
RE: separating C from V in MVC
From: Jesse Erlbaum [mailto:[EMAIL PROTECTED]] Sent: 30 May 2002 22:42 To: 'Ray Zimmerman'; modperl List; Mason List Jesse, thanks for your comments, I found them very interesting. I am comfortable with Perl and Web programming (though previously not the two together) and am about to embark on development of a new product for an ASP, so have considerable interest at this stage of the proceedings. I would like to ask some further questions, please forgive the extensive haircut of your comments: applying a design pattern such as MVC is not a panacea I agree - I much prefer Perlish DWIM dweomer Model: The business logic. Not related to the UI at all. View: The user interface. Controller: The glue between the View and the Model. ... the Model is simply a Perl module... make it entirely separate from the user interface... the methods... being called from a web application, a cron script, or an email-based interface Makes sense, in old-style speak [yes, I am approaching 'Ancient of Days' status] this seems to indicate the Model accepts method calls and returns data that will be rendered elsewhere. In our planned development, there is a LOT of tabular data - do you use any standards for the data being returned to the Controller? eg do you use a struct [ie hash/array Perl primitive] or do you return an object? eg a table object etc? The View, in a web application, is really the HTML output. Sounds good, so I could also pass the Models returned data to a different flavoured rendering view eg PDF, Spreadsheet, Text etc. This sounds a lot like our existing Perl reporting infra which does exactly that. W3 did a huge amount of analysis on layout and style as part of the CSS specs. In our setup, the table objects contain lots of style info. It is easy to render complex tables in PDF [as HTML will be] but formats like Excel are very hard, as there are layout constraints [eg a column can have only one width for the entire page - we call this the 'Highlander Effect'] Is this true of your setup? does the Model returned data contain lots of style hints? Or do you leave this completely to the View layer? How does the view layer know for example to render an Error cell as RED in HTML but blue in Excel due to Excel palette limitations? Optimally, the View avoids *ALL* application logic. - so the Model has to say RED rather than ERROR? but that wouldn't work if rendering something where RED is illegible? Our reporting knows about basic things like Error, Good, User Date / Numeric preferences etc. At my company we use HTML::Template ... it's damn fast, too will look at this - is there a list somewhere? The Controller connects the View to the Model... takes user input ... translates it into method calls on the Model... then takes output from the Model and passes it to your View. Sounds like Controller only interacts with one Model? I would assume that a Controller might collect data from a number of Models, and then pass the collection of data to a View? What controls the overall layout? e.g. what is the equivalent of the 'Grid Bag' layout manager - is this done in the Controller? and then passed to the View with all the data from a set of Models? Or do you make the Controller minimalist and have a meta-Model that assembles all the sub-Models into a layout. CGI::Application modules will do some reading on this also then. separating the View from Controller is a problem. I guess this is a balance between purist and DWIMism, but as we already have this separation for reporting, I would like to extend it into our dynamic web page generation. If you have to work with an SPS such as Mason but you still want to separate your View from your Controller, you have to work twice as hard. Interesting! Jesse, I found your posting extremely useful - thank you very much! Regards Jeff
RE: separating C from V in MVC
From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: 01 June 2002 00:17 To: Rob Nagler Cc: [EMAIL PROTECTED] The same template? How does the layout manager help with that? Does it modify the template? It would make more sense to me if this were a sort of abstraction to factor out common layout ideas from multiple templates. The layout manager is more complex than a static template. It takes a collection of data and meta-data and creates a document tree that is not a specific rendering flavour - the DOM might subsequently be rendered in NS4.0 HTML, IE5.01+ HTML, Excel, PDF etc. without requiring (every page) x (every format) x (every option) templates. ... That doesn't require a layout manager though. Simple templating is fine for that, i.e. two different templates (views). In most circumstances it is ok to have templates that are specific to one output flavour, possible with some simple alts. But what if I have 40 pages that I want to render in: IE5+HTML, NS4-HTML, Excel, HP-PCL5 and PDF - and I also want SIMPLE views of each page. This would result in 40 x 5 x 2 = 400 templates. For every change in a basic page, I have to keep 9 other templates in other languages in step. If the number of output formats and page variants is not trivial, it might make more sense to have an active component that creates the document tree, and passes it to simple components that know how to render a DOM in the desired output format. All in all, I think the MVC+template approach described is fine for most of the type of dynamic sites currently available on the web. But I work for a small ASP and we have to manage rapidly changing complex dynamic sites and complex user reporting requirements, with minimal work. We don't have any HTML specialists, but rather a few very good technical generalists. I think that for us a meta-data layout driven approach will be more effective. We do however plan to borrow all the good ideas we can find from any other model, including MVC+template. Our planned move to mod_perl is mostly due to the benefits we have seen from out Perl data processing and reporting - hence the desire to join both the web and DP infra at the hip. Regards Jeff
RE: separating C from V in MVC
From: Per Einar Ellefsen [mailto:[EMAIL PROTECTED]] Sent: 01 June 2002 18:10 To: Jeff Well, as I see this, it isn't a problem. The layout manager takes the place of the view, as it essentially decides how things should be rendered. You then have two stages in your view, but the same techniques apply (as the 2nd stage of the view isn't really specific to any model or controller). It is interesting to try and fit our approach into the MVC+template pattern, and I guess it comes down to where you draw the line. I think that the layout manager / creation of the document object model is not really part of a View, as a single DOM can be passed to a number of rendering components. I see it more as something the controller creates and passes to all of the Views that you want to implement. For example lets say that I want to present both a web page, and also render an Excel report in response to a single query [the page gets sent back to the requestor, the Excel gets saved into the db as a blob for later download]. I would see this happening like this: Controller: 1) creates collection of Models and model meta-data 2) creates DOM using layout hints in meta-data 3) passes DOM to HTML View and reaps the HTML rendering 4) passes DOM to Excel View and reaps the Excel rendering 5) saves the Excel rendering in the DB as a blob 6) returns the HTML view to the page requester As you can see from this outline, the controller manages the creation of the DOM outside either the HTML or Excel views. I see the Controller as also responsible for deciding what to do with the results of rendering the DOM in Excel or HTML formats - Views don't decide how their results should be distributed. In the above example, the Controller might decide to return the Excel object to the client, and save the HTML view into a cache or blob etc etc. This is my current thinking. Now that I have heard more details from the MVC folks on the list, I will have to sit down and spend some mental effort in assimilating MVC+template into what we currently do, and see what sort of beast emerges. Regards Jeff
RE: separating C from V in MVC
From: Barry Hoggard [mailto:[EMAIL PROTECTED]] Sent: 01 June 2002 19:16 I don't think the standard HTML::Template has support for formatting numbers, dates, etc. Perrin indicated that you can extend HTML::Template in some way to accommodate this, but I am not yet sure of the details. How do you make sure that it's done consistently in your applications? It seems problematic to me to require the programmers to do work when a designer wants to change the number of decimals in a page, for example. In our reporting infra we handle this by extending the number of basic data types to include things like cash value quantity interest rate market price and then set up a central store of meta-data that says xxx = cash value yyy = interest rate and then set up the extended data types cash value = '#,##0.00' quantity = '#,##0' we also allow field specific overrides zzz= '#,###' [blank when zero] All our components use the meta-data to determine how the result should look. In Excel, quantities are rendered with both a numeric value and a picture. Excel itself handles the commify. In PDF, the rendering component has to create a commified string representation with the correct number of dps. By centralising the meta-data and having rendering components that use your meta-data, you can globally change the accuracy or presentation rules in all view formats. At present, all our folks are Perl literate, so the metadata is very easily managed in a series of Perl modules, but there is nothing stopping you from storing it in a DB, text file etc and creating a non-technical user maintenance interface. Regards Jeff
RE: separating C from V in MVC
From: Rob Nagler [mailto:[EMAIL PROTECTED]] Sent: 31 May 2002 23:48 Models can only express meta info about the data, not the context in which the data is rendered. Some info, like placement, is conditional on the grouping which is chosen by the view. A layout manager abstracts placement using meta data supplied by the model and context supplied by the view. This is an interesting comment. We have so far tried [successfully] to keep our document object models completely independent of the rendering component, which means the same DOM can be passed to an Excel/PDF/etc component for rendering. The challenge of course is that it is much easy to render complex things in HTML than for example Excel which imposes a global tablular view where a column can only have one width for a page. Excel does however support multiple pages, but HTML doesn't [frames?]. Whilst one can rely on scroll-bars for HTML, PDF rendering requires the component to decide on wrapping or truncating to fit page widths. We relied heavily on the layout analysis that the W3 did for CSS and HTML when desiging our DOM class, and so HTML rendering is easy. As Rob mentions in one of his emails, the HTML rendering component does not actually have to calculate final layout, as this is done by the browser. Final layouts do have to be managed by some of our other rendering components - the PDF rendering component has to understand all flow, wrap, alignment, trunctation etc layout info. Your comment seems to hint that maybe the DOM should take into account the target rendering flavour eg craft a complex DOM for HTML but a simple DOM for Excel. We chose to make our rendering components all accept complex DOMs and then make their own decisions on to best render them taking into account limitations of the target format. I don't know if this was the right decision, but it has met our requirements for fast reporting development times for over a year now, and I am hoping to take it into the HTML world. I somehow feel that the MVC and MVC+template patterns described so far in the discussions go a long way towards, but do not quite reach our desired level of reusable infra. Templating is an interesting variant, but actually solves a different problem. Perhaps we are wanting too much! I can certainly see that the MVC+ template approach is simpler, and this is the strongest point in its favour. Regards Jeff
RE: separating C from V in MVC
From: Jesse Erlbaum [mailto:[EMAIL PROTECTED]] Sent: 30 May 2002 22:42 To: 'Ray Zimmerman'; modperl List; Mason List Jesse, thanks for your comments, I found them very interesting. I am comfortable with Perl and Web programming (though previously not the two together) and am about to embark on development of a new product for an ASP, so have considerable interest at this stage of the proceedings. I would like to ask some further questions, please forgive the extensive haircut of your comments: applying a design pattern such as MVC is not a panacea I agree - I much prefer Perlish DWIM dweomer Model: The business logic. Not related to the UI at all. View: The user interface. Controller: The glue between the View and the Model. ... the Model is simply a Perl module... make it entirely separate from the user interface... the methods... being called from a web application, a cron script, or an email-based interface Makes sense, in old-style speak [yes, I am approaching 'Ancient of Days' status] this seems to indicate the Model accepts method calls and returns data that will be rendered elsewhere. In our planned development, there is a LOT of tabular data - do you use any standards for the data being returned to the Controller? eg do you use a struct [ie hash/array Perl primitive] or do you return an object? eg a table object etc? The View, in a web application, is really the HTML output. Sounds good, so I could also pass the Models returned data to a different flavoured rendering view eg PDF, Spreadsheet, Text etc. This sounds a lot like our existing Perl reporting infra which does exactly that. W3 did a huge amount of analysis on layout and style as part of the CSS specs. In our setup, the table objects contain lots of style info. It is easy to render complex tables in PDF [as HTML will be] but formats like Excel are very hard, as there are layout constraints [eg a column can have only one width for the entire page - we call this the 'Highlander Effect'] Is this true of your setup? does the Model returned data contain lots of style hints? Or do you leave this completely to the View layer? How does the view layer know for example to render an Error cell as RED in HTML but blue in Excel due to Excel palette limitations? Optimally, the View avoids *ALL* application logic. - so the Model has to say RED rather than ERROR? but that wouldn't work if rendering something where RED is illegible? Our reporting knows about basic things like Error, Good, User Date / Numeric preferences etc. At my company we use HTML::Template ... it's damn fast, too will look at this - is there a list somewhere? The Controller connects the View to the Model... takes user input ... translates it into method calls on the Model... then takes output from the Model and passes it to your View. Sounds like Controller only interacts with one Model? I would assume that a Controller might collect data from a number of Models, and then pass the collection of data to a View? What controls the overall layout? e.g. what is the equivalent of the 'Grid Bag' layout manager - is this done in the Controller? and then passed to the View with all the data from a set of Models? Or do you make the Controller minimalist and have a meta-Model that assembles all the sub-Models into a layout. CGI::Application modules will do some reading on this also then. separating the View from Controller is a problem. I guess this is a balance between purist and DWIMism, but as we already have this separation for reporting, I would like to extend it into our dynamic web page generation. If you have to work with an SPS such as Mason but you still want to separate your View from your Controller, you have to work twice as hard. Interesting! Jesse, I found your posting extremely useful - thank you very much! Regards Jeff
RE: separating C from V in MVC
, quantities should be commified, cash values must have commas and 2dps, interest rates should have 4dps and cells with an error attribute should have a red background. mmm - I will also think more about the layout manager - methinks I need to mull over other possible implementation arrangements... I wrote about this in my article on the eToys system: http://www.perl.com/pub/a/2001/10/17/etoys.html I remember reading this at the time - and will re-read it with a fresh perspective. Thanks again for all the info and experience. Regards Jeff
Confusion: Perl/mod_perl ????
Hi, I have been programming in Perl for about 3 weeks now, and I just started doing some Perl CGI. I have Apache 2 installed on my linux system, but and my perl scripts work fine, but I don't knwo whether or not I'm using Perl (as in /usr/bin/perl) or mod_perl. I thought up untill recently that Apache has it's own version of Perl that it uses for CGI scripts (mod_perl) but I am now having doubts. Could someone please tell me exactly what the difference is between Perl and mod_perl, and how exactly mod_perl is used (.i.e. is it just for writing apache modules or is it just for CGI, or what) I'm big-time confuesd here. Thanks very much!!! Jeff.
RE: Configuring mod_perl on Debian
From: Andrew McNaughton [mailto:[EMAIL PROTECTED]] Sent: 27 May 2002 21:02 To: Ian D. Stewart ... You miss most of the advantage of debian's package management if you start building core components independently. Debian looks after you pretty well, but it's a bit of an all or nothing affair. ie it's worth a little effort to stick with the debian packages if you can. I agree with Andrew - getting Apache, Mod_SSL, PHP4 and mod_perl with PHP4/MySQL and mod_perl/mySQL all co-operating is a relative doddle with Debian packaging. Especially in view of the volume of the 'I cant build...' comments on the mod_perl mailing lists. We usually wget the .debs we want installed as a set, into a dir e.g. /usr/local/deb/build date and then do a dpkg -i *.deb apt-get check FYI, these are SOME of the installed packages on our Dev server yes - it's a bit messy, but it's potato flavoured, with woody extras, and we don't seem to have any issues. - apache 1.3.23-1Versatile, high-performance HTTP server apache-common 1.3.23-1Support files for all Apache webservers libapache-mod-ssl 2.8.7-1 Strong cryptography (HTTPS support) libssl0.9.60.9.6c-1SSL shared libraries mysql-client 3.23.46-2 mysql database client binaries mysql-common 3.23.46-2 mysql database common files libmysqlclient 3.23.38-2 mysql database client library perl 5.6.1-7 Larry Wall's Practical Extraction and libperl5.6 5.6.1-7 Shared Perl library. libapache-dbi-perl 0.88-5 Connect apache server to database via libapache-mod-perl 1.26-2 Integration of perl with the Apache web libapache-reload-perl 0.07-1 Reload changed modules in a mod_perl libapache-request-perl 0.33-1 Generic Apache Request Library libapache-session-perl 1.54-1 Perl modules for keeping persistent libapache-ssi-perl 2.16-1 perl Apache::SSI - Implement Server Side libdbd-mysql-perl 1.2216-2 mySQL database interface for Perl libdbi-perl1.21-2 The Perl5 Database Interface by Tim Bunce php4 4.1.2-1 A server-side, HTML-embedded scripting php4-mysql 4.1.2-1 MySQL module for php4 php4-pear 4.1.2-1 PEAR - PHP Extension Application Reposit -
mod_perl: User Authentication recommendations requested
I have a requirement to protect all pages on a website, and to only allow in users with a valid user id, password, client certificate and recognised IP. I know this is asking a lot, but I would appreciate an overview/recommendation of approaches that are 1st safe, and 2nd fast. I think something like: Scenario 1: unauthenticated user gets authenticated 1) user hits site - no session = unauthenticated create new session, remember requested page, redirect to /login page 2) /login page: collect username/password, POST action is /authenticate 3) /authenticate page: perform checks, if all ok set $session-is_logged_in(TRUE); and redirect to originally requested page [stored in session] Scenario 2: authenticated user accesses site 1) user hits page - has session redirect to /login if ( not $session-is_logged_in() ); redirect to /login?message=inactivity+timeout if ( time-$session-last_access()1hr ); Which seems to fit the functionality bill - users can bookmark their favourite part of the system. When they come in but have not yet authenticated, they get momentarily diverted through the /login/authenticate pages. Is this safe? How should I ensure that the sessions never get hijacked? I am thinking along the lines of an additional transient cookie issued when the session authenticates the user that contains md5(some_secret+session_id) that is also checked? And... is there already a nifty mod_perl class that does all this? I have Apache::AuthCookie working from examples, but don't know what the security implications of using it are, without reading the code [which I will do soon I guess]. I also have problems with the LOGIN POST saying POST: METHOD NOT ALLOWED when I try to get mod_perl to be the handler for Location /. Any recommendations/feedback appreciated! Even if it's a recipe I haven't yet reached! Thanks in advance, Jeff
RE: mod_perl: User Authentication recommendations requested
And then he reads on p360 that there are tantalising recipes in chapter 13... I would still appreciate the lists thoughts and experience. -Original Message- From: Jeff AA [mailto:[EMAIL PROTECTED]] Sent: 14 May 2002 09:07 To: [EMAIL PROTECTED] Subject: mod_perl: User Authentication recommendations requested I have a requirement to protect all pages on a website, and to only allow in users with a valid user id, password, client certificate and recognised IP. I know this is asking a lot, but I would appreciate an overview/recommendation of approaches that are 1st safe, and 2nd fast. I think something like: Scenario 1: unauthenticated user gets authenticated 1) user hits site - no session = unauthenticated create new session, remember requested page, redirect to /login page 2) /login page: collect username/password, POST action is /authenticate 3) /authenticate page: perform checks, if all ok set $session-is_logged_in(TRUE); and redirect to originally requested page [stored in session] Scenario 2: authenticated user accesses site 1) user hits page - has session redirect to /login if ( not $session-is_logged_in() ); redirect to /login?message=inactivity+timeout if ( time-$session-last_access()1hr ); Which seems to fit the functionality bill - users can bookmark their favourite part of the system. When they come in but have not yet authenticated, they get momentarily diverted through the /login/authenticate pages. Is this safe? How should I ensure that the sessions never get hijacked? I am thinking along the lines of an additional transient cookie issued when the session authenticates the user that contains md5(some_secret+session_id) that is also checked? And... is there already a nifty mod_perl class that does all this? I have Apache::AuthCookie working from examples, but don't know what the security implications of using it are, without reading the code [which I will do soon I guess]. I also have problems with the LOGIN POST saying POST: METHOD NOT ALLOWED when I try to get mod_perl to be the handler for Location /. Any recommendations/feedback appreciated! Even if it's a recipe I haven't yet reached! Thanks in advance, Jeff
unable to use method type handlers?
Whenever I try to set up a method type handler PerlHandler my::classes-mymethod I get the following in the error log: Undefined subroutine my::classes-mymethod::handler called. using: Apache/1.3.23 (Unix) Debian GNU/Linux mod_perl/1.26 mod_ssl/2.8.7 OpenSSL/0.9.6c any hints would be appreciated
RE: unable to use method type handlers?
Try per load the class my::class via startup.pl or PerlModule I already had PerlModule my::classes in httpd.conf Tried PerlRequire as well - still the same error help?? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: 14 May 2002 09:58 To: Jeff AA Cc: [EMAIL PROTECTED] Subject: Re: unable to use method type handlers? Try per load the class my::class via startup.pl or PerlModule Tor. Jeff AA wrote: Whenever I try to set up a method type handler PerlHandler my::classes-mymethod I get the following in the error log: Undefined subroutine my::classes-mymethod::handler called. using: Apache/1.3.23 (Unix) Debian GNU/Linux mod_perl/1.26 mod_ssl/2.8.7 OpenSSL/0.9.6c any hints would be appreciated
Perrenial Sessions: An Object Interface?
Folks,
A pol of gee's in advance - this is probably an inane question for ye
olde mod_perl gods but I'll ask it anyway to see if I get struck by the
lightning of enlightenment!
All the e dot gee's that I can find, perldoc and guide pages show
sessions being used with a tied old hash interface - I was wondering if
there is an new style object interface?
Something like:
my $session;
if ( exists $jar-{session} ) {
# restore the session from server storage
$session_id = $jar-{session}-value();
$session = Apache::Session::File-open( $session_id, { isnew = 0,
opened = ht_time(time()) } );
LogFatal Didn't find session: $session_id unless $session;
} else {
# Create a new session and remember the ID in a cookie
$session = Apache::Session::File-new( $session_id, { isnew = 1,
newtime = ht_time(time()) } );
$session_id = $session-{_session_id};
my $sessionCookie = Apache::Cookie-new( $r,
-name = 'session',
-value = $session_id,
-path = '/',
-domain = 'www.nowhere.com',
);
$sessionCookie-bake();
}
TIA
Jeff
Logging Perl errors to browser
Folks, How do I get to log my mod_perl handler Perl errors to the browser instead of into the Apache logs? TIA Jeff
RE: framesets/AuthCookie question
I'm just a budding modperlie - is notes info maintained
across a server redirect?
$r-internal_redirect('/login?message=dont+go+there');
Jeff
-Original Message-
From: Michael Schout [mailto:[EMAIL PROTECTED]]
Sent: 19 April 2002 17:44
To: Peter Bi
Cc: Fran Fabrizio; [EMAIL PROTECTED]
Subject: Re: framesets/AuthCookie question
On Wed, 17 Apr 2002, Peter Bi wrote:
Fran:
You may need to 1) add a few lines of code in AuthCookie to make your
error
code aware to other methods, and 2) have a dynamic login page that
can
interpret the code. Alternatively, you may try AccessCookie I posted.
:-)
The CVS version of AuthCookie has a custom_errors() hook in it that does
this
sort of thing.
However, I dont think it will work for his problem because his
javascript code
seems to launch a NEW REQUEST, thus loosing anything that was stored
away in
$r-subprocess_env(). So the only viable option is to pass the error
codes in
they url (as part of the query string) I think.
Mike
RE: Enforcing user logged in from only 1 browser?
Forgive a mod_perl newbie for non mod_perl thinking, but this is (a simplified overview) of how I would approach this: request for any protected page - if no existing session data [so not authenticated] create new session remember target page in session redirect to login page otherwise allow access to page login page POST with user id / password. - if ( valid user / password ) add user info to session expire previous session [id was saved in db] save new session id in the database [for next login] redirect to the originally requested page otherwise redirect to login page with error message If someone now tries to come back with an old session id, there is no data in the session, so they will be considered un-authenticated, and will get redirected to login page. In PHP, I would expire the old session during login, by deleting the session storage, if it still existed. mod_perlers can probably best suggest how to empty the contents of a session and / or remove the session storage. As the decisions are made based on information on the server, this should also be safe from users pressing the BACK button, as BACK to a protected page will redirect to login. I'm not sure what happens with using History to select the page that immediately followed login - probably the usual 'Do you want me to post again?' question from Explorer etc. I can see two issues with this approach: 1) login ping-pong. Two users using the same id/password will be logging each other out as they log in (but this seems to be what you want?) 2) it does not prevent the user from having the same pages open multiple times within the same browser instance (eg when the user presses Ctrl-N after having logged in) just my 2 newbie pennies... Regards Jeff -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: 15 April 2002 16:02 To: Fran Fabrizio Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Enforcing user logged in from only 1 browser? Fran Fabrizio wrote: Unfortunately, there's some terminology muddling...AuthCookie calls it a session when it establishes that a user is a valid user and sets a cookie on their browser. Apache::Session considers a session a series of page hits from the same user. It assumes you've already done whatever you need to do to assure that the user is valid. I think you may find that neither of these does everything you need without a bit of additional coding. The common way to do this sort of thing is to use Apache::Session to track sessions (as in a series of page hits from the same user), and if the user authenticates, you put his user ID into the session data. You would have to do the auth part yourself, as well as the actual cookie handling, or else hack AuthCookie to cooperate with Apache::Session. - Perrin
RE: PDF generation
Of course others have already told you about Text::PDF, and no doubt you googled the group Yahoo! http://groups.yahoo.com/group/perl-text-pdf-modules/messages You can do anything you want with PDFs, but the interface is hard to grok and you really need to wrap it. I have a framework that we use to pull info from a database on-the-fly, and generate either Excel spreadsheets, Text dumps or PDFs. It ain't really ready for public primetime. I put out a message about 6 months ago in the PDF list asking if anyone wanted to co-operate with me on getting it ready for realworld. The goal is to be able to create some relatively simple Perl structures and then throw them at a Spreadsheet, PDF, HTML or other rendering engine and reap the rewards! The doc tree used [i.e. Perl structures] leant heavily on the CSS analysis done by the w3 guys on how to organise layout and styles etc in such a way as to be independent of the ultimate rendering environment. Here is the post where I postulate an ideal universe where data is automagically formatted in wondrous tabular PDF prose... http://groups.yahoo.com/group/perl-text-pdf-modules/message/468 mail me direct if you want to help take it further. Regards Jeff -Original Message- From: Thomas Eibner [mailto:[EMAIL PROTECTED]] Sent: 08 April 2002 13:47 To: modperl Subject: Re: PDF generation On Mon, Apr 08, 2002 at 01:32:58PM +0200, Patrick wrote: Few seconds, at least for my cases (and by doing PUSHs to the Web client it let it know exactly where we are at the generation). Okay, that sounds bareable. You should also consider, if possible, to generate files in advance of use. That would have been a possibility if there wasn't such a high impact when you generate the statistics I need. I also think that should not mess with the PDF output directly. Because it looks like text, but as you show yourself, it is in fact more complicated. That is true, but it's a fine line between either having to do ALL the work everytime a layout has to change (try getting any of your graphical designers to make a layout in LaTeX :( ) or just parsing a PDF. And since placing content at an absolute position isn't really an option either it's not possible just to import the PDF and then write the information needed to the document. I wonder how much PDI from pdflib.org will do.. -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/
RE: mod_perl Cook Book
I bought it two weeks ago, as a mod_perl newbie, and recommend it. I really like the cookbook style: 'You want to XXX' = snippet / recipe. If you already read Perl, it is fast and compact. I have had questions along the way [specific to the cookbook], but posting a question on this list gets an almost immediate response. Summation: Worth the money - buy it. Regards Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 05 April 2002 21:13 To: [EMAIL PROTECTED] Subject: mod_perl Cook Book Hello folks, Has anyone purchased the mod_perl cook book from this list? If so, what do you think of it? Is it a good buy? Appreciate feed back. Thanks in advance -r
mod_perl developers cookbook... a kitchen hand asks... doh!
Just Curious of Hither Green writes:
I feel like a right tit for asking this...
I already have mod_perl et al running, including my persistent DB
connections etc etc, but following gourmet cookery advice on this list
induced me to buy a copy of the mod_perl Developers Cookbook... and yes,
my nails were rather short after the week it took my Amazon to deliver
said arcane tome unto my abode.
So, I am working my way through, and get to page 83 which has a little
spellette:
sub handler {
my $r = shift;
print STDERR $r-as_string();
return OK;
}
looks easy peasy - but
1) OK - Bareword OK not allowed while strict subs in use
well, that's easy to fix - I must be missing a 'use' [which one??]
I assume OK is 1 - ie TRUE
2) error log: Subroutine handler redefined at xxx line 1
This is interesting - probably because PerlHandler Apache::Registry so
kitchen whizzes, tell me please, exactly what knead I put in my
httpd.conf instead of Apache::Registry?
Thanks a munch!
Jeff
RE: Tie hashes in DBIx::Recordset [OT]
Obviously sorting the hash keys wont give you the columns
in the select statement order.
After doing something like:
my $sth = $dbh-execute(@params) or die...
You can get back the lower case column names in the select
statement order using:
my @names = @{$sth-{NAME_lc}};
Note that $sth-{NAME_lc} is not always populated, depending
upon your SQL.
Regards
Jeff
-Original Message-
From: Ged Haywood [mailto:[EMAIL PROTECTED]]
Sent: 13 March 2002 10:30
To: Marcus Claesson
Cc: [EMAIL PROTECTED]
Subject: Re: Tie hashes in DBIx::Recordset [OT]
Hi there,
On Wed, 13 Mar 2002, Marcus Claesson wrote:
How do I succesfully preserve the column order (''$fields'=
$joined_col') in my array-of-hashes generated using DBIx::Recordset?
Check out a Perl tutorial or the Camel book. Perl's hashes do their own
thing with ordering, so unless you do something like (sort keys %hash)
you will get what you get. Arrays can preserve sequences but involve
you in more coding much of the time.
73,
Ged.
Newbie help - My cookies won't bake?
Revered Chefs,
Please forgive a mere mod_perl kitchen-hand, undergoing early cookie
training... I have the following cookie code, but no cookies come
back when I refresh, and I don't see any $HTTP_COOKIE in %ENV.
$cookies ends up as a hash ref pointing to an empty hash.
I have the following in my httpd.conf:
PerlWarn On
PerlTaintCheck On
PerlFreshRestart On
PerlInitHandler Apache::Reload
PerlSetVar ReloadAll On
Files *.pl
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader Off
Options +ExecCGI
/Files
Help?? TIA
Jeff
# As you will note, this highly original recipe was lifted unchanged
# from Delia Smith's 'How to Boil Eggs for Breakfast'.
#
# This is the cookie dough that don't want to bake
use strict;
require dumpvar.pl;
use Apache;
use Apache::Cookie;
# read in the cookie if this is an old session
my $r = Apache-request();
my $cookies = Apache::Cookie-fetch;
my $sent = '';
if (!$cookies-{foo} ) {
$sent = 'sending cookie';
my $cookie = Apache::Cookie-new(
$r,
-name= 'foo',
-value = 'bar',
-expires = '+1D',
-domain = undef,
-path= '/',
-secure = undef,
);
$cookie-bake;
} else {
$sent = 'received cookie';
}
$r-content_type(text/html);
$r-send_http_header;
print $0 $sent, HR;
main::dumpValue(\$cookies);
print HR, $r-as_string, HR;
map { print nbsp;nbsp;$_ = '$ENV{$_}' BR\n; } sort keys %ENV;
#
Can anyone recommend a good flavour of Cookie?
Please forgive a mod_perl wannabie [aka woza.PHP4.user] I have googled two differing flavoured cookies in the mod_perl recipe library: Apache::Cookie Apache::RequestNotes and of course, there is the 'Why not hack the HTTP_COOKIE env all by your lonesome?' peppermint flavour too! So which is it folks? Please vote for your favourite flavour of cookie for poor woza.PHP4.user Thanks in advance! Jeff. PS Any kind Debian soul might also include the name of the .deb containing said flavour? PPS Not too keen on the taste of hysterical raisins.
Re: Status of mod_perl 2.0
On Wed, 2002-02-27 at 13:00, Stas Bekman wrote: Jeff Stuart wrote: Question? What is the status of mod_perl 2.0? Also, is it working with/playing with Apache 2.0 at all? Tell me what's the status of apache 2.0 and I'll tell you the status of mod_perl 2.0 :) But seriously mod_perl 2.0 will be ready about the time apache 2.0 (i.e. httpd-2.0) gets released. You can start playing with it already. I've successfully run my singlesheaven.com code using mod_perl 2.0 a few months ago. And there are many tests, so you can see what works and what not. Registry is almost completed, a few thread-safety issues unresolved (e.g. chdir() in the threaded env). If you plan on adding a testing platform for you product, make sure to use the Apache::Test framework from 2.0 distro, which rocks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ Heh... status of Apache 2.0? WHO Knows? LOL
Status of mod_perl 2.0
Question? What is the status of mod_perl 2.0? Also, is it working with/playing with Apache 2.0 at all?
perl cgi's and apache
I am having a problem getting my cgi script to complete processing when it is launched via apache server. The script itself runs fine from the command line. It is a script that processes a long array of values and interacts with a database per value. When the array is relatively short, the program will complete and everything is fine (even when launched through the browser). When the array is larger, and only when launched through the browser, the perl.exe on the Windows 2000 machine just seems to hang after about 30 seconds or so and if I stop apache server, it will start processing again and finish its job. I think I have all the apache timeout parameters set long enough. Can anyone help me out on this? Thanks
Re: load balancing on apache
On Fri, 14 Dec 2001, Perrin Harkins wrote: I _really_ hate so-called dedicated boxes. They're closed, nasty, inflexible and often don't work in _your_ situation. Doing smart session-based redirection can be hard with these boxes. You can make it work with homegrown solutions, but I've found the dedicated load-balancing tools (at least Big/IP) to be effective and fairly easy to work with, even with large loads, failover requirements, and more exotic stuff like sticky sessions. This is one area where the problem seems to be well enough defined for most people to use an off-the-shelf solution. They're often more expensive than they should be, but if you don't have someone on hand who knows the ipchains or LVS stuff it can save you some time and trouble. I couldn't agree more. In terms of managability and scalability, the various software solutions simply add complexity to something that is already so. I've got some experience with Alteon AceDirectors and even though they seem little flakey at times, you do end up with true load balacing. (We have Cisco's solution deployed and they periodically have issues too.) DNS round-robin should be avoided at all costs. It's half-assed at best. In the case of a failure those clients that have that IP cached are SOL. On some of the systems that I've deployed we have a frontend proxy on the same box as the mod_perl with the mod_perl server listening on 127.0.0.1. This is behind an Alteon (or 2). You can put the proxy on a separate box as well but (I've seen some odd problems with TCP connections not working in this situation which I never fully understood but may have had to do with the Alteon being flakey.) Anyway, my advice is to go with a hardware load balancer/intelligent IP switch. In the long term, it will pay for itself in the time recovered from *not* being spent on troubleshooting complex problems. --Jeff -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin, Historical Review of Pennsylvania, 1759.
mod_perl vs. C for high performance Apache modules
Hi All, Recently I did a substantial project for a client in using mod_perl. That client is happy with the work, but an investor with their company is very angry because of what a horrible choice mod_perl is for high-load web applications compared with Apache modules and even CGI programs, written in C. If anyone on this list could forward any resources that do comparisons along these lines, or even analysis of mod_perl's handling of high-load web traffic, I would be very grateful. Cheers, Jeff -- Jeff Yoak 626-705-6996
Re: mod_perl vs. C for high performance Apache modules
At 09:15 PM 12/14/2001 +0100, Thomas Eibner wrote: The key to mod_perl development is speed, there are numerous testimonials from users implementing a lot of work in a very short time with mod_perl. Ask the clients investor wheter he wants to pay for having everything you did rewritten as an Apache module in C. That is very likely going to take a lot of time. Thank you for your reply. I realized in reading it that my tone leads one to the common image of a buzzword driven doody-head who wants this because of what he read in Byte. That's certainly common enough, and I've never had a problem dealing with such types. (Well... not an unsolvable problem... :-) This is something different. The investor is in a related business, and has developed substantially similar software for years. And it is really good. What's worse is that my normal, biggest argument isn't compelling in this case, that by the time this would be done in C, I'd be doing contract work on Mars. The investor claims to have evaluated Perl vs. C years ago, to have witnessed that every single hit on the webserver under mod_perl causes a CPU usage spike that isn't seen with C, and that under heavy load mod_perl completely falls apart where C doesn't. (This code is, of course, LONG gone so I can't evaluate it for whether the C was good and the Perl was screwy.) At any rate, because of this, he's spent years having good stuff written in C. Unbeknownst to either me or my client, both this software and its developer were available to us, so in this case it would have been faster, cheaper and honestly even better, by which I mean more fully-featured. So he's upset. Everyone acknowledges that given our particular circumstances, it would have been better to build upon what we already had, but because of his previous experience he feels that mod_perl wasn't even a responsible choice even within the limits of our lack of knowledge of his software and its availability. So I'm trying to show that mod_perl doesn't suck, and that it is, in fact, a reasonable choice. Though within these limits it is still reasonable to point out the development cycle, emotionally it is the least compelling form of argument, because the investor has a hard time removing from consideration that given our particular situation, there was a very fast solution in using his C-based routines. Take a look at Joshua Chamas benchmarks (Although they're only hello world style apps) it shows that mod_perl is pretty fast. I will look for this particularly. Thanks. Cheers, Jeff -- Jeff Yoak 626-705-6996
Re: mod_perl vs. C for high performance Apache modules
All, I wasn't sure what volume of response to expect when I originally wrote. Thank you all for the comments that you all are making. They are helping. Given that the response is fairly high, I'm waiting for stuff to roll in rather than replying to each of you. Don't think it is falling on unappreciating ears. :-) To respond to a few recurring comments / questions: Me? I've spent most of the last four years working on mod_perl-based stuff and most of the last eight working with Perl. Actually I've worked with folks who were involved with some of the projects you've mentioned, having been at idealab!, a parent of eToys and CitySearch. One of the original (THE original?) developer at CitySearch was probably the most helpful mentor / teacher I've ever worked with. I programmed in C a lot early in my career, but at this point I couldn't write anything substantial without brushing up, and frankly wouldn't care to. It just isn't as fun to work with C. But then, the argument, But if you used C, you wouldn't get to work with ME! may not convince some of these people with their values all screwed up... ;-) The project? What I consider to be standard web junk. About 30% ecommerce combined with lots of database-driven, interactive content, some authentication foo and things like that. The thing is that it is in the adult industry and the investor in question turns on the hose... well... there will be lots of traffic. Mistakes and misunderstandings? Sure. And yes, as some of you have pointed out publicly or privately, not my fault. I was kept very insulated from the people who were familiar with the alternatives. My involvement at this point is to try to smooth things over and keep the project functional. These immediate problems aside, the people involved are great to work with and if everyone feels better about the situation and things move forward in the best possible way from here, there will be a lot of valuable work for me. So I'm trying to help. More than you cared to hear about and terribly off-topic for the list? Sure. But you did sorta ask, and somehow it seemed rude to not reply. Forgive me and thanks for providing all of your commentary. Cheers, Jeff -- Jeff Yoak 626-705-6996
Re: DBI connections build up..
On Thu, 13 Sep 2001, DJ (David J Radunz) wrote:
use strict;
use vars ($dbh);
You don't need this with Apache::DBI. Globals in general should be
avoided/used with extreme caution.
use mod_perl;
Don't need this either.
1;
END {
$dbh-disconnect;
}
Put this before the '1;' or just don't use it.
Read the guide front to back: http://perl.apache.org/guide/
HTH.
Jeff
--
Jeff Beard
___
Web:www.cyberxape.com
Email: jeff at cyberxape dot com
Earth: Boulder, CO, USA
Re: Children dying
I've got the same configuration and it's working fine. No seg faults unless I cause'em. If nothing else is giving you adequate information, you can always remove code until it works. Not very elegant but it works consistently. --Jeff On Tue, 14 Aug 2001, darren chamberlain wrote: Aleksandr Vladimirskiy [EMAIL PROTECTED] said something to this effect on 08/14/2001: I am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. I get the following error in my logs: perl 5.6.0 has DynaLoader bug that minifests itself under mod_perl. Upgrade to 5.6.1, downgrade to 5.00503, or wait for 5.8.0 to fix the bug. (darren) -- Jeff Beard ___ Web:www.cyberxape.com Email: jeff at cyberxape dot com Earth: Boulder, CO, USA
Re: Regarding the PerlAuthenHandler[2]
You should see this one. Compiled-in modules: -- snip -- mod_perl.c see http://perl.apache.org/guide/install.html for how to build mod_perl against apache Jeff On Fri, May 11, 2001 at 04:50:21PM -, qazi Ahmed wrote: Hi.. When i am giving the command: ./httpd -l in the bin directory of apache i get the following details: rad-sun-2 ./httpd -l Compiled-in modules: http_core.c mod_env.c mod_log_config.c mod_mime.c mod_negotiation.c mod_status.c mod_include.c mod_autoindex.c mod_dir.c mod_cgi.c mod_asis.c mod_imap.c mod_actions.c mod_userdir.c mod_alias.c mod_access.c mod_auth.c mod_setenvif.c suexec: disabled; invalid wrapper /export/home/ats/test-tools/ats/guts/apache/bin/suexec rad-sun-2 What should i get actually to confirm that mod_perl is installed properly. And further if suexec is an error, please reply by sending the solution to overcome it. Thanks and regards Qazi - Original Message -- Owen Boyle [EMAIL PROTECTED] wrote: To:qazi Ahmed [EMAIL PROTECTED] From:Owen Boyle [EMAIL PROTECTED] Date:Fri, 11 May 2001 14:01:11 +0200 Subject: Re: Regarding the PerlAuthenHandler qazi Ahmed wrote: Syntax error on line 547 of /export/home/ats/test-tools/ats/guts/apache/conf/httpd.conf: Invalid command 'PerlRequire', perhaps mis-spelled or defined by a module not included in the server configuration Are you *really* sure you have installed mod_perl? Try ./httpd -l to list the modules and check.. Rgds, Owen Boyle. _ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com Thanks, Jeff -- | Heres milk in your eye.. | | and on your shirt, shorts, couch, and floor. | |- Matthew Scott Sheffield | | (@ six months old)| -- | Jeff Sheffield | | [EMAIL PROTECTED] | | AIM=JeffShef ICQ=4340529 Yahoo=jsheffieus | | NowDocs http://www.nowdocs.com (day gig) | --
Re: [OT] JMS-like event framework for Perl
Might be possible that soap is addressing messaging issues. Nathan Torkington wrote: "Michael A. Nachbaur" wrote: Since today seems to be "The Day of the Off Topic(tm)", I thought I'd jump in with my question. Is there a event messaging framework available for Perl, similar to JMS? I'd like to be able to have an object registered as a handler for certain "events", and have perl code throw those events causing the object to be run automatically (publish / subscribe model). I think there's an Event.pm, but you're probably after something like POE: http://www.perl.com/pub/2001/01/poe.html - intro and tutorial http://poe.perl.org/ - homepage (down?) http://poe.dyndns.org/ - Rocco's dialin machine Nat -- Perl/Linux/Java Development Resume: http://resumes.yahoo.com/undertheash/perljavalinux
Re: [JOB] Perl expert for hire
ditto for me. but include c++, corba,html and an interest soap and mason. drop me a line if your interested in this power pack. but include "Jeffrey W. Baker" wrote: I am available for contract or permanent work beginning immediately. I am an expert in Perl programming, have a long history of experience with mod_perl, and can write Perl extensions in C. I am also a productive C programmer and a passable Java programmer. Recently I have begun dabbling in Apache core programming and embedding the Perl engine in C programs. You may view my resume at http://atari.saturn5.com/ Best regards, Jeffrey Baker -- [EMAIL PROTECTED] 415.279.0768
Unexpected PATHINFO behavior under SSL
Hi there, This may be offtopic-ish but I'm hoping for some forbearance. This has ruined a perfectly good day. :) I have an application that gets it state information from PATHINFO. Runs fine without SSL but I setup a test env using Raven SSL then PATHINFO, and SCRIPT_NAME, start returning different data. For instance the program handler would be called /foo and I'll add /bar to the path to trigger a behavior. Under SSL, the SCRIPT_NAME is set to /foo/bar and PATHINFO is empty. Without SSL, SCRIPT_NAME is /foo and PATHINFO is bar. This is Apache 1.3.12, mod_perl 1.24, Raven 1.5.3 on RH Linux 6.2. mod_perl was built with EVERYTHING=1. All modules were statically built. Perl 5.00503. Ideas? TIA, Jeff -- Jeff Beard ___ Web:www.cyberxape.com Email: jeff at cyberxape dot com Earth: Boulder, CO, USA
Re: Help with configuration - Linux/Mandrake 7.2
Maybe: Files ~ "\.pl$" ... /Files I think there's some documentation on this issue as well. --Jeff On Sun, 18 Feb 2001, Rich Feather wrote: I'm trying to get my Apache Web Server to read *.pl files using mod_perl (standard Linux-Mandrake 7.2). Under perl, it works fine and, indeed, in httpd-perl.conf, it shows Alias perl /var/www/perl Directory /var/www/perl SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options ExecCGI -Indexes /Directory Also, I've tried up the following Directory /var/www/html SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options ExecCGI -Indexes /Directory and/or Files *.pl SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI /Files Restarted after each change /etc/rc.d/init.d/httpd restart ...but I cannot get the server to parse *.pl files using mod_perl. Any ideas? Thanks. -- Jeff Beard ___ Web:www.cyberxape.com Email: jeff at cyberxape dot com Earth: Boulder, CO, USA
Re: Apache::Registry, mod_perl interface, and post data
On Fri, 16 Feb 2001, Andrew Ho wrote: form method="post" action="post.pl" input type="hidden" name="hello" value="world" /form I added a button and push it. It works. ;) --Jeff -- Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape dot com Earth: Boulder, CO, USA
Re: Apache::Registry, mod_perl interface, and post data
On Fri, 16 Feb 2001, Andrew Ho wrote: Hello, JBI added a button and push it. It works. ;) Urgh, I had a button on my actual test page; it just magically disappeared when I retyped it in the e-mail. I don't think the problem is with what you posted. I tried your snippets on two different systems and they worked as expects. What's your config look like? Do you get the 'Post = ()' output from the Registry script? Are you running any other software that might interfere? --Jeff -- Jeff Beard ___ Web:www.cyberxape.com Email: jeff at cyberxape dot com Earth: Boulder, CO, USA
Re: Send a cookie, AND a redirect ?
Read the POD docs for Apache under the heading 'Setting up the response';
--Jeff
On Thu, 8 Feb 2001, Harrison wrote:
Dear All.
I can set a cooke fine using:
$r-content_type('text/html');
$r-header_out('Set-Cookie' =$cookie);
$r-send_http_header;
And i can also send a redirect fine using:
$r-content_type('text/html');
$r-header_out('Location'=$the_url);
return REDIRECT;
BUT!
how do i do both? if i use my redirect code, and add an extra header_out , the
cookie is not sent (because i have not called send_http_header ? ).
If i add send_http_header, i see the full sent http_header in my browser.
My idea was to have something like
$r-content_type('text/html');
$r-header_out('Location'=$the_url);
$r-header_out('Set-Cookie' =$cookie);
$r-send_http_header;
return REDIRECT;
Which does not work.
Thinking about it whilst typing this email, does header_out have a field where i can
set the REDIRECT status?
Thanks in advance,
Richard Harrison.
--
Jeff Beard
_
Web:www.cyberxape.com
Email: jeff at cyberxape dot com
Earth: Boulder, CO, USA
Re: ticketsystem
I noticed that the MS Explorer remembers both username and corresponding password, making the cookie based authentication system useless. (closing and reopening all windows does not help) pure evil..!! (IMHO) I don't use exploder very often... is this really true..?? On Wed, Jan 10, 2001 at 11:08:37PM +0100, [EMAIL PROTECTED] wrote: Hi I am using a cookie based authentication scheme. Cookie expires therefore login again. ( like the ticket master example in O'reilly's.) I noticed that the MS Explorer remembers both username and corresponding password, making the cookie based authentication system useless. (closing and reopening all windows does not help) So using the default browser preferences is no good. Does anybody know which browser preference is involved here. Arnold Thanks, Jeff | If you go to the zoo, always take somethin' to feed the animals | | even if the signs say "Do not Feed Animals." It wasn't the | | animals that put them signs up. | | -- Forrest Gump | | -- Winston Groom | ---- | Jeff Sheffield | | [EMAIL PROTECTED] | | AIM=JeffShef |
Re: mod-perl on Solaris 2.6
Check out the mailing list archive for something I posted a while back. It boiled down to not using GNU binutils for anything. Including GCC. --Jeff -- Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape dot com Earth: Boulder, CO, USA On Mon, 8 Jan 2001, Siddhartha Jain wrote: Hi, I have been trying to compile mod-perl (various 1.21 to 1.24_01 ) on Solaris 2.6 with apache (various 1.3.11 to 1.3.14) with perl-5.005003 and also perl-5.6. If i compile it statically, i get a core dump on running apache and if i compile it via apxs, i get a "Symbol not found main, in libperl.so" error. I had compiled perl-5.6 using Solaris's malloc and later i compiled perl-5.005 with perl's malloc but nothing helped. I am mostly at my wits ends having tried all sorts of combinations. Could someone help me? Siddhartha Jain
Re: perl calendar application
build something large. (Trying to build a garden with three different climates and have it work as one big garden is a huge challenge and certainly not worth pursuing if you're trying to maximize production.) I agree with this... however if you have to play in that garden because half of you developers are PHP developers and have are perl developers. then take a look at this module. Apache::ProxyStuff I believe the module was originally written to play will with domonio apps. We used it to have a mason back ended server playing with a php back ended server and then unifying the site. This is really cool when you are "lazy" and you wan to install some app that already written. no more Gosh darn ... that is just what I need guess i will have to port it. Jeff On Sun, Jan 07, 2001 at 11:38:24AM -0500, [EMAIL PROTECTED] wrote: On Sat, 6 Jan 2001, Blue Lang [EMAIL PROTECTED] espoused: Eh, I'm prepared to take my lynching, but I'd just like to remind everyone that there's nothing at all wrong with using PHP for things like this. You'll never be a worse person for learning something new, and the overheard required to manage a php+perl enabled apache is only minimally more than managing one or the other. IMHO, it's just lame to rewrite something for which there exists dozens of good apps just because of the language im which it is written. You might as well be arguing about GPL/BSD/Artistic at that point. I'm not going to get sucked into a language advocacy debate. But at least in my case, your comments are quite off base. A) I don't need to learn PHP. I learned PHP four or five years ago. The experience wasn't pleasant. My most recent experience with PHP was to port a PHP3 app from PostgreSQL to MySQL. It was very tedious and still unpleasant. (Yes PHP4 supposed finally has a real database interface like DBI, but most of the apps out there aren't written for PHP4.) B) Simplicity is good. The fewer things running inside my web server to meet my needs the better. This is a security issue as well as an ease of maintenance issue. C) We are organizationally committed to perl. Our employees and contractors are not expected to know PHP and most are quite happy that I don't make them write in PHP. A long term strategy of keeping my programmers (including myself) happy seems like a good thing. D) (And I think this is the most important point of all.) There are good reasons for deciding on a language and sticking with it if your hope is to build something large. (Trying to build a garden with three different climates and have it work as one big garden is a huge challenge and certainly not worth pursuing if you're trying to maximize production.) My hope is to take the calendar portion of things and build upon it. Ultimately I'd like to have something that has the functionality of Outlook plus bugzilla. I've gotten several emails privately with offers of source for various "in progress" projects that people say they're willing to make open source. I will keep the list informed. -- /chris Those who cannot remember the past are doomed to buy Microsoft products. Thanks, Jeff --- | "0201: Keyboard Error. Press F1 to continue." | | -- IBM PC-XT Rom, 1982 | --- | Jeff Sheffield | | [EMAIL PROTECTED] | | AIM=JeffShef| ---
Re: the edge of chaos
this is not the solution... but it could be a bandaid until you find one. set the MaxClients # lower. # Limit on total number of servers running, i.e., limit on the number # of clients who can simultaneously connect --- if this limit is ever # reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW. # It is intended mainly as a brake to keep a runaway server from taking # the system with it as it spirals down... # MaxClients 150 On Wed, Jan 03, 2001 at 10:25:04PM -0500, Justin wrote: Hi, and happy new year! My modperl/mysql setup does not degrade gracefully when reaching and pushing maximum pages per second :-) if you could plot throughput, it rises to ceiling, then collapses to half or less, then slowly recovers .. rinse and repeat.. during the collapses, nobody but real patient people are getting anything.. most page production is wasted: goes from modperl--modproxy--/dev/null I know exactly why .. it is because of a long virtual "request queue" enabled by the front end .. people "leave the queue" but their requests do not.. pressing STOP on the browser does not seem to signal mod_proxy to cancel its pending request, or modperl, to cancel its work, if it has started.. (in fact if things get real bad, you can even find much of your backend stuck in a "R" state waiting for the Apache timeout variable to tick down to zero..) Any thoughts on solving this? Am I wrong in wishing that STOP would function through all the layers? thanks -Justin Thanks, Jeff --- | "0201: Keyboard Error. Press F1 to continue." | | -- IBM PC-XT Rom, 1982 | --- | Jeff Sheffield | | [EMAIL PROTECTED] | | AIM=JeffShef| ---
Apache::AuthCookieDBI BEGIN problems...??
Well been racking my brain against this one for awhile now..
so I figured that I would reach-out for some help ;)
First let me say
I am ashamed ... I twitled with the shiny bits.
the following code in the Apache::AuthCookieDBI module
does not work properly (for me).
-- code --
BEGIN {
my @keyfile_vars = grep {
$_ =~ /DBI_SecretKeyFile$/ } keys %{ Apache-server-dir_config() };
foreach my $keyfile_var ( @keyfile_vars ) {
my $keyfile = Apache-server-dir_config( $keyfile_var );
my $auth_name = $keyfile_var;
$auth_name =~ s/DBI_SecretKeyFile$//;
unless ( open( KEY, "$keyfile" ) ) {
Apache::log_error( "Could not open keyfile for $auth_name in
file $keyfile" );
} else {
$SECRET_KEYS{ $auth_name } = KEY;
close KEY;
}
}
### MY DIRTY HACK
my $auth_name = "WhatEver";
$SECRET_KEYS{ $auth_name } = "thisishtesecretkeyforthisserver";
### END MY DIRTY HACK
}
-- end code --
Note that without MY DIRTY LITTLE HACK it does not set those two
variables. I am/was pretty sure that this somehow relates to
"StackedHandlers"
but
I built mod_perl statically with ALL_HOOKS=1 EVERYTHING=1
it is Apache/1.3.14 (Unix) mod_perl/1.24_01 configured
So after I set MY DIRTY LITTLE HACK. Things chug right along
i bind to the database I authenticate against the db.
until I/the module tries to set_cookie in the form
Set-Cookie:
Apache::AuthCookieDBI_WhatEver=jeff:2001-01-02-23-07-10:2001-01-02-23-12-10:2f8e147086c88e6771ac6751b5a1f25d;
path=/; domain=.jeff
So that makes me wonder if Date::Calc is installed correctly.
i.e. he module uses Date::Calc. also note that it installed fine.
I figured that the cookie problem could be a side effect of the
firt problem I mentioned.
ahh yes my config file is here for anyone who is intrested
Any clue's..??
Thanks,
Jeff
-
| Gender Diff's |
| THOUGHT FOR THE DAY: Any married man should forget his mistakes. |
| There's no use in two people remembering the same thing. |
| |
| --Anonymous |
-----
| Jeff Sheffield|
| [EMAIL PROTECTED]|
| AIM=JeffShef |
-
Re: Apache::AuthCookieDBI BEGIN problems...??
ahh yes my config file is here for anyone who is intrested oopse http://www.jspot.org/jeff/temp/custom.after Thanks, Jeff - | Gender Diff's | | THOUGHT FOR THE DAY: Any married man should forget his mistakes. | | There's no use in two people remembering the same thing. | | | | --Anonymous | - | Jeff Sheffield| | [EMAIL PROTECTED]| | AIM=JeffShef | -
Unset PerlAuthenHandler (I wish)
Ok, essentially I want all but one directory on the server to be password protected. I want 1 directory to have the "I forgot my password" functionality. I am using Mason. and setting SetHandler default-handler has undesired results. i.e. mason files do not get parsed. Essentially I want to do this. Unset PerlAuthenHandler here is a portion of my conf file. -- AddType text/html .mhtm FilesMatch ".*\.mhtm$" SetHandler perl-script PerlHandler HTML::Mason /FilesMatch Location /websites/foo.net/htdocs/ AuthName "foo" AuthType Basic PerlAuthenHandler Apache::AuthDBI::authen PerlAuthenHandler Apache::AuthDBI::authz PerlSetVar Auth_DBI_data_source dbi:mysql:database=foo_external_site;host=localhost;port=3306 PerlSetVar Auth_DBI_username jsheffie PerlSetVar Auth_DBI_password fooo # DBI-connect($data_source, $username, $password) PerlSetVar Auth_DBI_pwd_table users PerlSetVar Auth_DBI_uid_field user_id PerlSetVar Auth_DBI_pwd_field password PerlSetVar Auth_DBI_grp_field groups #SELECT pwd_field FROM pwd_table WHERE uid_field=$user require valid-user ErrorDocument 401 /websites/foo.net/htdocs/passwd_forgoten/ /Location Location /websites/foo.net/htdocs/passwd_forgoten/ SetHandler default-handler /Location - Any ideas..?? Thanks, Jeff --- | 7.6.2.1. Configuring /etc/diphosts | | | | (taken from the Linux Networking-HOWTO) | --- | Jeff Sheffield | | [EMAIL PROTECTED] | | AIM=JeffShef| ---
Re: Connection Pooling / TP Monitor
The only way I really see this working is in a threading environment. First of all, for some databases database connections don't survive forking (Oracle is the notable example here). Also, even if we could get forking to work, we would still get the scaling problem we are trying to avoid. Instead of Oracle keeping a huge list of persistent connections, the Connection Pool would keep a huge list of persistent connections. In both cases each connection would map to a Unix process and all these processes would chew up OS resources big time! - Original Message - From: "Matt Sergeant" [EMAIL PROTECTED] To: "Tim Bunce" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; "Jeff Horn" [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 27, 2000 7:02 AM Subject: Re: Connection Pooling / TP Monitor On Fri, 27 Oct 2000, Tim Bunce wrote: Sounds like just a CORBA/RPC type thing. Wouldn't you be better off using CORBA::ORBit? Maybe. I dunno. I don't actually need this stuff, I just want there to be a solution out there for those that do. I'm waving my hands around and pointing in various directions hoping someone will _do_ something! Hehe... OK, lets think about exactly what is needed here then. I figure Doug's Apache::DBIPool module (for mod_perl 2.0) is exactly the right architecture: 2 pools of connections (Busy and Waiting) New connections always taken from the head of Waiting Finished connections always replaced on the head of Waiting Threaded architecture (DBI::Oracle handles don't survive a fork) One thread for management One thread per connection once a handle has been supplied Some sort of timeout mechanism for connections if the pool is fully allocated Anything I've missed? If we don't go the threaded route, we can't easily expand and contract the connection pool I don't think - but I'd love to be proved wrong. Also an entire Apache server for the connection pool would be too much - the pre-forking server from the cookbook would be better. And it should even work on Win32 now... -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
sending Apache::ASP output to a variable?
I would like to Apache::ASP to parse pages in an existing mod_perl environment. Ideally, I could set headers with mod_perl, then use Apache::ASP to parse templates which I can arbitrarily combine. It seems that using Apache::ASP forces me to do most of my coding in the perlscript whereas I would prefer to minimize this for the sake of not interspersing too much code within the HTML. As it stands, it appears that the output of Apache::ASP goes directly to stdout. Is there a way to use Apache::ASP as part of a normal mod_perl module, then capture the output to a variable? Or perhaps there is a better solution using Mason? Jeff Ng Lead Web Developer onDevice Corp. [EMAIL PROTECTED]
Apache::ASP + Apache::Filter - how fast? (was:sending Apache::ASP output to a variable?)
Thanks Ged. I started down that path, but found that Apache::Filter combined with Apache::ASP basically does the job I need. There are a few limitations, but it should be good enough. The only remaining concern is speed. Does anyone have experience with this setup? Thanks. Jeff. it appears that the output of Apache::ASP goes directly to stdout. Is there a way to use Apache::ASP as part of a normal mod_perl module, then capture the output to a variable? Have a look at sub PRINT and sub PRINTF in ASP.pm, I'm sure you can do what you want there. Check out the Eagle Book if you're unsure about tied filehandles. 73, Ged.
Connection Pooling / TP Monitor
First let me say that I'm aware that this topic comes up with some frequency on the mod_perl and DBI-users list. I am aware of posts like this one: http:[EMAIL PROTECTED] which argue against the necessity of pooling. However, I am also aware of a _major_ ISP that implements their email system using a _major_ RDBMS that has had problems that are best solved via connection pooling. Essentially, the time it takes them to search through all the cached connections is nearly as long as the time it is taking to read/write to the database. Although, I'm not implementing email as this ISP is, I think that scalability in my case may definitely run into similar roadblocks. I am interested in hearing from anyone that has tried to implement true connection pooling either within Apache or as an external process. I'm particularly interested in hearing about implementations that could be made to work or are done using Perl and DBI/DBD. I am mostly interested in things that are Open Source or licensed like Perl itself. I am aware of a project called Gnu Transaction Server (GTS), but it doesn't seem like this is quite ready for prime time at the moment or is even under active development. I've seen posts that hint at using shared memory and IPC to implement this within Apache as well as posts that hint at possibilities of implementing this using DBI::Proxy. I basically want to do what the big TP monitors (Tuxedo/Encina/CICS) do with respect to condensing connections to a database, but I'm not in need of features like two-phase commit, cross database joins, heterogeneous database environment, etc. incorporated in these products. Even if you'd simply be interested in working on such a project, I'd like to hear from you. If you think such a project is plain stupid, I'd also be interested in hearing from you (but be gentle!). If you already have something sort of working along these lines, I'd DEFINITELY be interested in hearing from you! -- Jeff Horn
Re: Apache trouble reading in large cookie contents
There are techniques in the Eagle book for storing data in a cookie. (Check out the discussion on maintaining state) However, in my experience, you'll do better in the long run using something like Apache::Session. It'll be a scalable solution. --Jeff On Fri, 20 Oct 2000, Biggs, Jody wrote: I'm having trouble when a browser sends a fair sized amount of data to Apache as cookies - say around 8k. I know that most clients will not allow cookies greater than 4k per cookie (and often no more than 20 per hostname), and as such have broken the cookie being sent out to be sent in smaller chunks, with names such as 'Cookie0', 'Cookie1', 'Cookie2', etc., which I would later concatenate back together to obtain the full data that I had originally sent out. However, when the browser sends data back to Apache, it sends all the cookies on the same header line (Cookie: Cookie0=...; Cookie1=...; Cookie2=...) and so on. Apache then complains (and fails the request) with a message of the sort: [date] [error] [client 1.2.3.4] request failed: error reading the headers and spits out an error screen to the user with essentially the same message, but including the "Cookie:" line I assume this is due to a compile time directive to Apache specifying the maximum size of a header line. Has anyone else run into this problem, and if so, could you point me in the right direction? Sorry if this seems to be a bit more of an Apache question than mod_perl. Thanks - Jody Biggs
Re: Apache 1.3.14 and Mod_Perl
Here's what I would do: Remove the rpm version of apache: # rpm -e packagename If you want to use the start up files that are part of that package just copy them some where since they'll be removed. Build the source version following the directions in the mod_perl document called INSTALL.apaci under the heading "The flexible way". Unless you have a specific reason for it, I wouldn't bother with building it as a DSO. It's usually not a problem on Linux but it adds a level of complexity. I used mod_perl 1.24_01 with Apache 1.3.14 last time and had no problems with the build. --Jeff On Mon, 16 Oct 2000, Annette wrote: I am new to Apache and Mod_Perl and I have a question. I am running Red Hat 6.0 on an Intel machine. I loaded the Server setup. Apache 1.3.6 is loaded and runs fine. I was able to load and run Mod_Perl RMS package from Red Hat as DSO. I want to upgrade to Apache 1.3.14 and latest version of Mod_Perl. Here are the steps I took to load Apache 1.3.14. /etc/rc.d/init.d/httpd stop I downloaded Apache_1.3.14.tar.gz to the /usr/src directory tar zvxf apache_1.3.14.tar.gz ./configure --prefix=/usr/local/apache make make install /usr/local/apache/bin/apachectl start I verified that Apache 1.3.14 is now running. How do I install the latest version of Mod_Perl? Every time I try to install it I receive a message stating I need Apache 1.3.0 and then it aborts. I tried Mod_Perl version 1.19, 1.21, and 1.24 and I receive the same error. Any input would be appreciated and I hope this is the right address to send my question. Ann.
RE: open(FH,'|qmail-inject') fails
If you are using qmail-inject in a high volume configuration, make sure you reduce or eliminate most of its logging, otherwise the system will spin its wheels doing logging work and not sending out emails. Haven't compared Net::SMTP to qmail-inject, but qmail-inject is significantly faster than straight sendmail on Linux. Jeff -Original Message- From: Doug MacEachern [mailto:[EMAIL PROTECTED]] Sent: Monday, September 25, 2000 5:21 PM To: Stas Bekman Cc: Bill Moseley; Modperl Subject: Re: open(FH,'|qmail-inject') fails On Mon, 25 Sep 2000, Stas Bekman wrote: All you care about is to measure the time between email sending start and end (when the process continues on its execution flow). Why should one care about the details of internal implementation. i only skimmed the first part of this thread, but assumed if you're talking about performance, you'd want to compare the overall impact on your system(s) of Net::SMTP vs. |qmail-inject. you cannot measure the overall impact just using Benchmark.pm is all i'm trying to clarify.
mm-1.0.12
ok, I know I am off the subject here, and I apologize, I am hoping somebody can help for I think I have exhausted all possible resources for help without actually asking a question here. I've been working on this issue for over a week. I'm trying to install apache with mod_ssl and mm-1.0.12 here is what i've done so far: # tar zxf open_ssl.0.9.5.tar.gz # ./config # make # make test # make install # tar zxvf /path/to/rsaref-2.0.tar.gz # cp -rp install/unix local # cd local # make # mv rsaref.a librsaref.a (just renameing it) # cd mm-1.0.12 # ./configure --disable-shared # make (I've tried the newer version of mm with no luck 1.1.3 and I've tried actually make install on both of them as well, which I shouldn't have to if I reference them like i do below) created this config script and ran it for mod_ssl: #!/bin/sh ./configure --with-apache=/usr/src/apache/apache_1.3.12 \ --with-ssl \ --with-rsa=../depend/rsaref-2.0/local \ --with-mm=../depend/mm-1.0.12 \ --enable-shared=ssl To this point I get no errors. Here is the configure script I run togetapacheconfigured: #!/bin/sh SSL_BASE=../modules/mod_ssl/depend/openssl-0.9.5 \ RSA_BASE=../modules/mod_ssl/depend/rsaref-2.0/local \ EAPI_MM=/usr/src/apache/modules/mod_ssl/depend/mm-1.0.12 \ ./configure \ --enable-module=ssl \ --enable-module=proxy \ --enable-shared=proxy \ --enable-module=rewrite \ --enable-shared=rewrite \ --prefix=/usr/local/apache-1.3.12 \ --enable-shared=ssl \ --enable-rule=EAPI \ --enable-rule=SHARED_CORE \ --enable-rule=SHARED_CHAIN \ --enable-module=so \ --activate-module=src/modules/frontpage/mod_frontpage.o \ --fpexec-caller=nobody \ --fpexec-uidmin=99 \ --fpexec-gidmin=99 \ --fpexec-fpuser=bin \ --fpexec-fpgroup=bin \ --server-uid=nobody \ --server-gid=nobodyHere is my output:Configuring for Apache, Version 1.3.12+ using installation path layout: Apache (config.layout)+ activated frontpage module (modules/frontpage/mod_frontpage.o)Creating MakefileCreating Configuration.apaci in srcfgrep: /usr/src/apache/modules/mod_ssl/depend/mm-1.0.12/.libs: Is a directoryfgrep: : No such file or directoryfgrep: /usr/src/apache/modules/mod_ssl/depend/mm-1.0.12/.libs: Is a directoryCreating Makefile in src+ configured for Linux platform+ setting C compiler to gcc+ setting C pre-processor to gcc -E+ checking for system header files+ adding selected modules o rewrite_module uses ConfigStart/End+ using -lndbm for DBM support enabling DBM support for mod_rewrite o ssl_module uses ConfigStart/End + SSL interface: mod_ssl/2.6.6 + SSL interface build type: DSO + SSL interface compatibility: enabled + SSL interface experimental code: disabled + SSL interface conservative code: disabled + SSL interface vendor extensions: disabled + SSL interface plugin: Built-in SDBM + SSL library path: /usr/src/apache/modules/mod_ssl/depend/openssl-0.9.5 + SSL library version: OpenSSL 0.9.5 28 Feb 2000 + SSL library type: source tree only (stand-alone) + SSL library plugin mode: RSAref (explicitly configured) + SSL library plugin path: /usr/src/apache/modules/mod_ssl/depend/rsaref-2.0/local/librsaref.a+ enabling Extended API (EAPI) using MM library: /usr/src/apache/modules/mod_ssl/depend/mm-1.0.12 (source-tree only)+ enabling DSO files to be linked against others+ enabling generation of Apache core as DSO+ using -ldl for vendor DSO support+ checking sizeof various data types+ doing sanity check on compiler and optionsCreating Makefile in src/supportCreating Makefile in src/regexCreating Makefile in src/os/unixCreating Makefile in src/apCreating Makefile in src/mainCreating Makefile in src/lib/expat-liteCreating Makefile in src/modules/standardCreating Makefile in src/modules/proxyCreating Makefile in src/modules/sslCreating Makefile in src/modules/frontpage Notice the fgrep errors (three of them) talking about mm? Why is this happening? TRUST ME, that is the directory to mm! Everything goes on to compile and it seems to work. However, I don't know how to test if mm is working or not. Anyhelp would be most appreciated. In fact if you could even point me to where I may get some help on mm that would be great too. I have not found anyplace. Thankyou for taking the time to help me, I appreciate it. Regards, Jeff
Re: Auto rollback using Apache::DBI
Yes, I ran into this while I was making a version of Apache::DBI which uses
'reauthenticate' to maintain a single connection per Apache child (per
database) and simply reauthenticate on that connection. It turned out that
I modified what $Idx was composed of and didn't understand why I was not
getting rollbacks when sessions ended without commits.
I too think that the cleanup handler should ALWAYS be pushed and that the
handler itself should check for the AutoCommit status before issuing a
rollback. Should be easy enough to implement.
-- Jeff
- Original Message -
From: "Honza Pazdziora" [EMAIL PROTECTED]
To: "Nicolas MONNET" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, September 07, 2000 9:17 AM
Subject: Re: Auto rollback using Apache::DBI
On Thu, Sep 07, 2000 at 04:03:04PM +0200, Nicolas MONNET wrote:
I might get something wrong, but while in non-autocommit, if a script
dies
before rollbacking or commiting, looks like the transaction never gets
cancelled until I kill -HUP httpd! Quite a problem ...
Is there any known way to catch this?
Looking at the code in Apache::DBI 0.87, the handle is only rollbacked
if the AutoCommit is set to zero during connect, not if you do
$dbh-{'AutoCommit'} = 0;
in your script.
I wonder if the $needCleanup test is wanted at all. We could make it
a configuration option, not to push the cleanup handler, but I believe
that generally the rollback is wanted thing in all cases.
--
Honza Pazdziora | [EMAIL PROTECTED] | http://www.fi.muni.cz/~adelton/
.project: Perl, DBI, Oracle, MySQL, auth. WWW servers, MTB, Spain, ...
Re: Poor man's connection pooling
One thing I've looked at doing is adding an LRU mechanism (or some such discipline) to the existing Apache::DBI. I've already modified Apache::DBI to use 'reauthenticate' if a DBD implements it so that only 1 connection needs to be maintained per child. This greatly improves performance with a 1:1 ratio between Apache children and database connections. However, some (most) DBD don't implement this method and in fact some databases cannot even do a 'reauthenticate' on an existing connection. Also, there are situations where performance can be greatly improved by a judicious choice of the # of connections maintained per child. An example of this is where one user is used to verify authentication info stored in a database and then if authenticated a new user id is used to actually do the work. In this case keeping 2 connections per Apache child, pins the common "authenticating" connection and rotates the other connection, while still keeping the total number of connections quite low. There are other disciplines besides LRU which might work well. Keeping a "Hot Set" of connections by keeping a count of how often they're accessed might a useful alternative. I'm sure there's all sorts of interesting disciplines that could be dreamed up! I'm looking at potential changes to Apache::DBI which would allow a choice of discipline (LRU, HotSet, etc.) along with whether or not to use 'reauthenticate' DBD function all configurable from apache config files. I'd be interested in any input on this course of action! -- Jeff Horn - Original Message - From: "Michael Peppler" [EMAIL PROTECTED] To: "Barrie Slaymaker" [EMAIL PROTECTED] Cc: "Michael Peppler" [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, September 06, 2000 12:24 PM Subject: Re: Poor man's connection pooling Barrie Slaymaker writes: Michael Peppler wrote: Based on preliminary tests I was able to use a 1 in 10 ratio of database handles per httpd child processes, which, on a large site would cut down on the number of connections that the database server needs to handle. I'd be interested to see how this compares with Apache::DBI performance with MaxRequestsPerChild = 100. I suspect it's negligable unless you're using a database like Oracle (with lots of connection establishment overhead) over a *slow* link. The back-end is Sybase. The actual connect time isn't the issue here (for me.) It's the sheer number of connections, and the potential issue with the number of sockets in CLOSE_WAIT or TIME_WAIT state on the database server. We're looking at a farm of 40 front-end servers, each runnning ~150 modperl procs. If each of the modperl procs opens one connection that's 6000 connections on the database side. Sybase can handle this, but I'd rather use a lower number, hence the pooling. I don't think there's any significant memory savings here, is there? Things you think might share physical memory probably don't after a SQL statement or two and some perl code gets run. Oracle certainly changes the RAM in their connection and cursor handles, for instance. I'm not worried about RAM usage on the web servers. Michael -- Michael Peppler -||- Data Migrations Inc. [EMAIL PROTECTED]-||- http://www.mbay.net/~mpeppler Int. Sybase User Group -||- http://www.isug.com Sybase on Linux mailing list: [EMAIL PROTECTED]
Re: [OT] Language Question...
I began teaching myself C using the following book: "A Book on C" by Al Kelley, Ira Pohl ISBN# 0201183994 It will turn up if you do a search at amazon. Hope this helps. Jeff Jones On Fri, 1 Sep 2000, David Hajoglou wrote: I would like to be able to read the internals of mod_perl (the module that plugs into apache). I would like to understand how it works with apache and to do this I need c coding skills. So, regardless of my reason for wanting to learn c (though it does relate), does anybody have any suggestions for a good book or set of books that one can learn c from (rather than just a language reference). On 1 Sep 2000, David Hodgkinson wrote: David Hajoglou [EMAIL PROTECTED] writes: Well, if you must know, mod perl was programmed in c I knew this. So? -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire -
Re: Migrating from CGI.pm to (...?), was Re: CGI.pm problem
Ah, so there is. I grep'd an older version which didn't since I'd never heard of it before. You use Apache::Request to get query parameters the same way you do with CGI.pm's param() method. perldoc Apache::Request. Did you could try just importing the CGI.pm HTML functions? Personally, I prefer Template Toolkit for HTML generation. There are other templating systems too. Search the archives for discussions on the subject. Or as Stas suggested, check out the version 3 beta. I've been using it on my personal web server for a few months with no problems, though I don't use any of the HTML generation features. --Jeff At 10:32 AM 8/30/00 +0400, Alexei V. Barantsev wrote: Jeff Beard [EMAIL PROTECTED] writes: There isn't a Vars() function in CGI.pm. If you're looking for the query string try param(). Or if you want to make it a mod_perl program (which is what you would normally discuss on this list) Apache::Request::param(). --Jeff There is such a function, Jeff! Well, could you advice, how to migrate from CGI.pm to Apache or Apache::Request. The matter is that I have used CGI.pm for HTML generation primarily and ready to use something another to analyze request parameters. But I cannot use CGI and e.g Apache::Request simultaneousely - server hangs. Is there some CGI.pm replacement intended only for HTML generation in the same manner (which does nothing with request, especially POST request)? -- ab ICQ: 3959207 Jeff Beard __ Web:www.cyberxape.com Email: jeff at cyberxape dot com Location: Boulder, Colorado, USA
Re: CGI.pm problem
There isn't a Vars() function in CGI.pm. If you're looking for the query string try param(). Or if you want to make it a mod_perl program (which is what you would normally discuss on this list) Apache::Request::param(). --Jeff At 04:11 PM 8/29/00 +0400, Alexei V. Barantsev wrote: Dear mod_perl'ers! I have found strange difference between object and func modes of CGI library. More precisely - I have a problem with Vars function. Let me show an example: #!/usr/bin/perl -w use Data::Dumper; use CGI; my $q = new CGI; my $args = $q-Vars; #use CGI qw(:standard :cgi-lib); #my $args = Vars; print header, start_html, p( Dumper( $args ) ), start_form( -method = "POST", -action = "/~barancev/cgi-perl/test.pl" ), textfield( -name = "name", -size = 50 ), submit( -name = "submit", -value = "Submit" ), submit( -name = "cancel", -value = "Cancel" ), end_form, end_html; All works ok, when I click button I see what button was pressed and what string was entered. But if I try functional way instead (commented in example) I see that $args is empty! In single-process mode (httpd -X) both examples work right. Why? (BTW, both examples was tried on clean, just started Apache) -- ab ICQ: 3959207 Jeff Beard ______ Web:www.cyberxape.com Email: jeff at cyberxape dot com Location: Boulder, Colorado, USA
Re: Getting data from external URL
I just wrote a function yesterday that uses IO::Socket to interact with an
outside CGI program. It appears to work the way I want but this is my first
foray into writing TCP client code.
It's basically this:
sub tcp_client {
my ( $rhost, $rport, $query_string ) = @_;
my $socket = IO::Socket::INET-new( PerrAddr = $rhost,
PeerPort = $rport,
Proto= "tcp",
Type = SOCK_STREAM)
or die "Couldn't connect to $rhost:$rport : $!\n";
print $socket "GET /programname?$query_string\n";
my $response;
while ( $socket ) { $response .= $_ }
close($socket);
return \$answer;
}
--Jeff
At 06:58 AM 8/28/00 -0400, Steve Reppucci wrote:
Just a word of warning: LWP::Simple doesn't follow redirects (at least,
the last I checked, not sure if it's been changed in the 3 or 4
months since I've last used it...), so you need to be certain that you're
using it in a context where you're fetching something that won't return a
redirect.
HTH...
On Sat, 26 Aug 2000, Stas Bekman wrote:
On Sat, 26 Aug 2000, Rodney Broom wrote:
OK, lots of banter...
Hey V, if you are on a *NIX system, then this is a fast way:
open U, "lynx -source www.some.url.dom |";
$data = join '', U;
There, you're finished. Admittedly, this isn't terribly efficiant,
but it works
just fine and has short devel time.
This one is much more efficient and requires even less coding:
use LWP::Simple;
$content = get("http://www.sn.no/")
And it doesn't require you to be on any particular OS, as far as I know.
see perldoc LWP::Simple and as advised by many others LWP::UserAgent for
more advanced uses.
=-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Steve Reppucci [EMAIL PROTECTED] |
Logical Choice Software http://logsoft.com/ |
508/958-0183 Be Open |
Jeff Beard
______
Web:www.cyberxape.com
Email: jeff at cyberxape dot com
Location: Boulder, Colorado, USA
Cookies
How do you set expires in ASP cookies?
I tried, and various other ways too. Even nodeworks.com wouldn't work for
me. Thanks.
$expires=HTTP::Date::time2str(time()+86400);
$Response-{Cookies}{'username','Expires', '$expires'} =
$Request-Form('username');
$Response-{Cookies}{'password'} = $Request-Form('password');
Jeff
