Re: asynchronous perl authentication!?
Even if you use AJAX, the page will still refresh because the AuthCookie module's authentication method redirect's you back to the login page so that the session cookie can be checked. You might be able to get around that by overloading the authentication method using a subrequest instead of a redirect, although I am not entirely sure that will work. Scott Gifford wrote: > > _spitFIRE <[EMAIL PROTECTED]> writes: > >> Hi All, >> I have written a simple perl module (using apache authcookie) for >> authenticating users. However, whenever the user types a wrong password, >> the entire page refreshes. Is it possible to do a ajax style >> authentication >> here??? I'm sorry if my understanding is seriously flawed (I'm still >> learning!). I would basically like to stop the entire page getting >> refreshed and have the normal ajax style login here; is that possible? > > This would have to happen on the client in Javascript. I've never > done it, but it seems likely to be possible; a Javascript forum might > have more knowledgeable users (or you may get lucky here!) > > Good luck, > > Scott. > > -- View this message in context: http://www.nabble.com/asynchronous-perl-authentication%21--tf3860218.html#a10984730 Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: [mp2] Segmentation faults with threaded worker-mpm
Perrin Harkins wrote: > Honestly, the person who has done the most work on debugging thread > crashes is Torsten. His advice on how to debug it will be better than > mine. It does seem like people usually solve them by using backtrace > analysis though. Getting back to this, I've now had time to install debug versions of mod_perl module and perl to the production server, and run backtraces on a core dump. Unfortunately I do not have the possibility to run a debug version of Apache right now, but hopefully that won't be needed. Looking at the backtraces for each thread, there are a couple things that I think I can see: - The segfault appears to happen when Apache attempts to recycle the child process (ap_graceful_stop_signalled in thread #1) - Threads 4 and 9 appear to be running perl, and those are also the only threads that show anything interesting (atleast to me) As per the instructions on mod_perl documention, I analyzed the perl threads a bit more closely. The 'curinfo' returns for both threads '536870923Cannot access memory at address 0x4040004'. If anyone has any ideas/thoughts on how to further debug the problem based on the backtraces, please let me know. Backtraces: (gdb) btt 1 [Switching to thread 1 (process 2094)]#0 0xb7cb2401 in __read_nocancel () from /lib/tls/libpthread.so.0 #0 0xb7cb2401 in __read_nocancel () from /lib/tls/libpthread.so.0 #1 0x0808b855 in ap_mpm_pod_check () #2 0x080894d5 in ap_graceful_stop_signalled () #3 0x08089656 in ap_graceful_stop_signalled () #4 0x08089715 in ap_graceful_stop_signalled () #5 0x0808a807 in ap_mpm_run () #6 0x0806232f in main () (gdb) btt 2 [Switching to thread 2 (process 2135)]#0 0xb7cb25fe in accept () from /lib/tls/libpthread.so.0 #0 0xb7cb25fe in accept () from /lib/tls/libpthread.so.0 #1 0xb7d0c5bd in apr_socket_accept () from /usr/lib/libapr-1.so.0 #2 0x0808b98c in unixd_accept () #3 0x08088b09 in ap_graceful_stop_signalled () #4 0xb7d10316 in apr_proc_detach () from /usr/lib/libapr-1.so.0 #5 0xb7cad0bd in start_thread () from /lib/tls/libpthread.so.0 #6 0xb7c3c9ee in clone () from /lib/tls/libc.so.6 (gdb) btt 3 [Switching to thread 3 (process 2134)]#0 0xb7c32ef9 in poll () from /lib/tls/libc.so.6 #0 0xb7c32ef9 in poll () from /lib/tls/libc.so.6 #1 0xb7d10145 in apr_wait_for_io_or_timeout () from /usr/lib/libapr-1.so.0 #2 0xb7d0b6b3 in apr_socket_recv () from /usr/lib/libapr-1.so.0 #3 0x0807b756 in ap_lingering_close () #4 0x08089153 in ap_graceful_stop_signalled () #5 0xb7d10316 in apr_proc_detach () from /usr/lib/libapr-1.so.0 #6 0xb7cad0bd in start_thread () from /lib/tls/libpthread.so.0 #7 0xb7c3c9ee in clone () from /lib/tls/libc.so.6 (gdb) btt 4 [Switching to thread 4 (process 2133)]#0 0xb77eb15a in modperl_mgv_as_string (my_perl=0x8662c58, symbol=0x8178190, p=0x8938438, package=0) at modperl_mgv.c:399 399 modperl_mgv.c: No such file or directory. in modperl_mgv.c #0 0xb77eb15a in modperl_mgv_as_string (my_perl=0x8662c58, symbol=0x8178190, p=0x8938438, package=0) at modperl_mgv.c:399 #1 0xb77df146 in modperl_callback (my_perl=0x8662c58, handler=0x8939ee8, p=0x8938438, r=0x8938470, s=0x80a88c8, args=0x870c29c) at modperl_callback.c:85 #2 0xb77dfb79 in modperl_callback_run_handlers (idx=5, type=4, r=0x8938470, c=0x0, s=0x80a88c8, pconf=0x0, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_ALL) at modperl_callback.c:263 #3 0xb77e00aa in modperl_callback_per_dir (idx=5, r=0x8938470, run_mode=MP_HOOK_RUN_ALL) at modperl_callback.c:370 #4 0xb77feb63 in modperl_fixup_handler (r=0x8938470) at modperl_hooks.c:57 #5 0x0806ff29 in ap_run_fixups () #6 0x08084528 in ap_process_request () #7 0x080817de in ap_register_input_filter () #8 0x0807b507 in ap_run_process_connection () #9 0x0808914b in ap_graceful_stop_signalled () #10 0xb7d10316 in apr_proc_detach () from /usr/lib/libapr-1.so.0 #11 0xb7cad0bd in start_thread () from /lib/tls/libpthread.so.0 #12 0xb7c3c9ee in clone () from /lib/tls/libc.so.6 (gdb) btt 5 [Switching to thread 5 (process 2132)]#0 0xb7cafc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #0 0xb7cafc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #1 0xb7d053da in apr_thread_cond_wait () from /usr/lib/libapr-1.so.0 #2 0x0808b2b3 in ap_queue_pop () #3 0x08088fc5 in ap_graceful_stop_signalled () #4 0xb7d10316 in apr_proc_detach () from /usr/lib/libapr-1.so.0 #5 0xb7cad0bd in start_thread () from /lib/tls/libpthread.so.0 #6 0xb7c3c9ee in clone () from /lib/tls/libc.so.6 (gdb) btt 6 [Switching to thread 6 (process 2131)]#0 0xb7c32ef9 in poll () from /lib/tls/libc.so.6 #0 0xb7c32ef9 in poll () from /lib/tls/libc.so.6 #1 0xb7d10145 in apr_wait_for_io_or_timeout () from /usr/lib/libapr-1.so.0 #2 0xb7d0b6b3 in apr_socket_recv () from /usr/lib/libapr-1.so.0 #3 0x0807b756 in ap_lingering_close () #4 0x08089153 in ap_graceful_stop_signalled () #5 0xb7d10316 in apr_proc_detach () from /usr/lib/li
Re: [mp2] Segmentation faults with threaded worker-mpm
On Wednesday 06 June 2007 10:55, Jani M. wrote:
> (gdb) btt 4
> [Switching to thread 4 (process 2133)]#0 0xb77eb15a in
> modperl_mgv_as_string (my_perl=0x8662c58, symbol=0x8178190, p=0x8938438,
> package=0) at modperl_mgv.c:399
> 399 modperl_mgv.c: No such file or directory.
> in modperl_mgv.c
> #0 0xb77eb15a in modperl_mgv_as_string (my_perl=0x8662c58,
> symbol=0x8178190, p=0x8938438, package=0) at modperl_mgv.c:399
> #1 0xb77df146 in modperl_callback (my_perl=0x8662c58,
> handler=0x8939ee8, p=0x8938438, r=0x8938470, s=0x80a88c8, args=0x870c29c)
> at modperl_callback.c:85
> #2 0xb77dfb79 in modperl_callback_run_handlers (idx=5, type=4,
> r=0x8938470, c=0x0, s=0x80a88c8, pconf=0x0, plog=0x0, ptemp=0x0,
> run_mode=MP_HOOK_RUN_ALL) at modperl_callback.c:263
> #3 0xb77e00aa in modperl_callback_per_dir (idx=5, r=0x8938470,
> run_mode=MP_HOOK_RUN_ALL) at modperl_callback.c:370
> #4 0xb77feb63 in modperl_fixup_handler (r=0x8938470) at modperl_hooks.c:57
> #5 0x0806ff29 in ap_run_fixups ()
> #6 0x08084528 in ap_process_request ()
> #7 0x080817de in ap_register_input_filter ()
> #8 0x0807b507 in ap_run_process_connection ()
> #9 0x0808914b in ap_graceful_stop_signalled ()
> #10 0xb7d10316 in apr_proc_detach () from /usr/lib/libapr-1.so.0
> #11 0xb7cad0bd in start_thread () from /lib/tls/libpthread.so.0
> #12 0xb7c3c9ee in clone () from /lib/tls/libc.so.6
...
> (gdb) btt 9
> [Switching to thread 9 (process 2125)]#0 0xb7b99d51 in kill () from
> /lib/tls/libc.so.6
> #0 0xb7b99d51 in kill () from /lib/tls/libc.so.6
> #1 0x0807c9bb in ap_fatal_signal_child_setup ()
> #2
> #3 0xb77eb15a in modperl_mgv_as_string (my_perl=0x85bc758,
> symbol=0x8178190, p=0x88ad7f8, package=0) at modperl_mgv.c:399
> #4 0xb77df146 in modperl_callback (my_perl=0x85bc758,
> handler=0x88af2a8, p=0x88ad7f8, r=0x88ad830, s=0x80a88c8, args=0x86eaf0c)
> at modperl_callback.c:85
> #5 0xb77dfb79 in modperl_callback_run_handlers (idx=5, type=4,
> r=0x88ad830, c=0x0, s=0x80a88c8, pconf=0x0, plog=0x0, ptemp=0x0,
> run_mode=MP_HOOK_RUN_ALL) at modperl_callback.c:263
> #6 0xb77e00aa in modperl_callback_per_dir (idx=5, r=0x88ad830,
> run_mode=MP_HOOK_RUN_ALL) at modperl_callback.c:370
> #7 0xb77feb63 in modperl_fixup_handler (r=0x88ad830) at modperl_hooks.c:57
> #8 0x0806ff29 in ap_run_fixups ()
> #9 0x08084528 in ap_process_request ()
> #10 0x080817de in ap_register_input_filter ()
> #11 0x0807b507 in ap_run_process_connection ()
> #12 0x0808914b in ap_graceful_stop_signalled ()
> #13 0xb7d10316 in apr_proc_detach () from /usr/lib/libapr-1.so.0
> #14 0xb7cad0bd in start_thread () from /lib/tls/libpthread.so.0
> #15 0xb7c3c9ee in clone () from /lib/tls/libc.so.6
Interesting both threads are at exactly the same line of code:
ptr = string = apr_palloc(p, len+1);
for (mgv = symbol; (package ? mgv->next : mgv); mgv = mgv->next) {
==> Copy(mgv->name, ptr, mgv->len, char);
ptr += mgv->len;
}
I suspect mgv has been corrupted. The question is who is the culprit?
Try "PerlInterpScope request" and see if the coredumps disappear. Further
check if it's always this place.
Torsten
pgpp0cPsBazKa.pgp
Description: PGP signature
Re: [mp2] Segmentation faults with threaded worker-mpm
Try "PerlInterpScope request" and see if the coredumps disappear. Further check if it's always this place. PerlInterpScope request did not help. I just tested, and still got a segfault. As far as I have seen, all the segfaults seem to be mgv related, but not at the exact same spot. One odd thing I noticed is that I have configured mod_perl to run 4 interpreters per process, yet I always see only 2 perl threads in the core dumps. Is there a reason for this? Since it looked like all the problems always occured in the FixupHandler phase, I tried moving the code I have there to HeaderParser phase, but that did not help. Here is an example backtrace from that test. Only one of the perl threads was in the HeaderParser phase this time - the other thread was polling for data from the client. [Switching to thread 12 (process 15427)]#0 0xb7bc0d51 in kill () from /lib/tls/libc.so.6 #0 0xb7bc0d51 in kill () from /lib/tls/libc.so.6 #1 0x0807c9bb in ap_fatal_signal_child_setup () #2 #3 0xb781149d in modperl_mgv_lookup (my_perl=0x8677208, symbol=0x812f8c0) at modperl_mgv.c:131 #4 0xb7811562 in modperl_mgv_lookup_autoload (my_perl=0x8677208, symbol=0x812f8c0, s=0x80a88c8, p=0x8937320) at modperl_mgv.c:153 #5 0xb78060f1 in modperl_callback (my_perl=0x8677208, handler=0x8939100, p=0x8937320, r=0x8937358, s=0x80a88c8, args=0x87cca2c) at modperl_callback.c:75 #6 0xb7806b79 in modperl_callback_run_handlers (idx=0, type=4, r=0x8937358, c=0x0, s=0x80a88c8, pconf=0x0, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_ALL) at modperl_callback.c:263 #7 0xb78070aa in modperl_callback_per_dir (idx=0, r=0x8937358, run_mode=MP_HOOK_RUN_ALL) at modperl_callback.c:370 #8 0xb7825a64 in modperl_header_parser_handler (r=0x8937358) at modperl_hooks.c:32 #9 0x080743f9 in ap_run_header_parser () #10 0x08071eb1 in ap_process_request_internal () #11 0x08084528 in ap_process_request () #12 0x080817de in ap_register_input_filter () #13 0x0807b507 in ap_run_process_connection () #14 0x0808914b in ap_graceful_stop_signalled () #15 0xb7d37316 in apr_proc_detach () from /usr/lib/libapr-1.so.0 #16 0xb7cd40bd in start_thread () from /lib/tls/libpthread.so.0 #17 0xb7c639ee in clone () from /lib/tls/libc.so.6 And here are is one more example when running in the FixupHandler phase, again crashing at a slightly different location. [Switching to thread 7 (process 11705)]#0 0xb7bb1d51 in kill () from /lib/tls/libc.so.6 #0 0xb7bb1d51 in kill () from /lib/tls/libc.so.6 #1 0x0807c9bb in ap_fatal_signal_child_setup () #2 #3 0xb78022d8 in modperl_mgv_compile (my_perl=0x81cf6c0, p=0x80a20d0, name=0x878bc62 "MyModule") at modperl_mgv.c:98 #4 0xb7802bd1 in modperl_mgv_resolve (my_perl=0x81cf6c0, handler=0x88bdaf0, p=0x80a20d0, name=0x88bdac0 "MyApache::MyModule::proxy_rewrite_handler", logfailure=0) at modperl_mgv.c:275 #5 0xb77f8cb0 in modperl_handler_resolve (my_perl=0x81cf6c0, handp=0xb451d274, p=0x88bc3d0, s=0x80a88c8) at modperl_handler.c:233 #6 0xb77f6e73 in modperl_callback (my_perl=0x81cf6c0, handler=0x88bdaf0, p=0x88bc3d0, r=0x88bc408, s=0x80a88c8, args=0x88c5ea0) at modperl_callback.c:39 #7 0xb77f7b79 in modperl_callback_run_handlers (idx=5, type=4, r=0x88bc408, c=0x0, s=0x80a88c8, pconf=0x0, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_ALL) at modperl_callback.c:263 #8 0xb77f80aa in modperl_callback_per_dir (idx=5, r=0x88bc408, run_mode=MP_HOOK_RUN_ALL) at modperl_callback.c:370 #9 0xb7816b63 in modperl_fixup_handler (r=0x88bc408) at modperl_hooks.c:57 #10 0x0806ff29 in ap_run_fixups () #11 0x08084528 in ap_process_request () #12 0x080817de in ap_register_input_filter () #13 0x0807b507 in ap_run_process_connection () #14 0x0808914b in ap_graceful_stop_signalled () #15 0xb7d28316 in apr_proc_detach () from /usr/lib/libapr-1.so.0 #16 0xb7cc50bd in start_thread () from /lib/tls/libpthread.so.0 #17 0xb7c549ee in clone () from /lib/tls/libc.so.6 -- Jani
Re: Which template engine is best to create a perl site
On 6/6/07, Octavian Rasnita <[EMAIL PROTECTED]> wrote: I have tested HTML::Template::JIT, but HTML::Template::Compiled was much faster than it. Sorry, but I suspect there's a mistake in your test. Possibly you counted the time for JIT to do the initial compile, which is slow but only happens once. HTML::Template::Compiled is fast, but it's not as fast as JIT. I don't recommend actually using JIT though, since it's harder to debug template coding mistakes with, and HTML::Template is fast enough. - Perrin
Re: asynchronous perl authentication!?
On 6/6/07, Adam Tistler <[EMAIL PROTECTED]> wrote: Even if you use AJAX, the page will still refresh because the AuthCookie module's authentication method redirect's you back to the login page so that the session cookie can be checked. If it's your AJAX request getting redirected, that shouldn't cause the page to refresh. It may require some changes to AuthCookie to get the effect you want though. Or you can go the easy way and use an IFRAME. - Perrin
Re: Which template engine is best to create a perl site
From: "Perrin Harkins" <[EMAIL PROTECTED]> Sorry, but I suspect there's a mistake in your test. Possibly you counted the time for JIT to do the initial compile, which is slow but only happens once. HTML::Template::Compiled is fast, but it's not as fast as JIT. I don't recommend actually using JIT though, since it's harder to debug template coding mistakes with, and HTML::Template is fast enough. - Perrin I have made the test using Apache's ab program, in a program that uses mod_perl, and the pages were displayed much more faster when using HTML::Template::Compiled. This happened 3 or 4 years ago if I remember well, and the things might have changed since then. Octavian
Apache Startup
Can someone point to a good place for docs on exactly how Apache starts. I've had a read through ... http://perl.apache.org/docs/2.0/user/handlers/server.html .. and my Apache Modules book isn't answering the questions I have. The problem is, I have startup.pl being run twice when it's only declared once in a .conf file which is Include(d) into httpd.conf. Also, in ENV, I only get to see MOD_PERL => mod_perl/2.0.3 MOD_PERL_API_VERSION => 2 PATH=my/list/of/paths from within startup.pl In my .conf file, startup.pl is called at the very end and before that I have quite a few PerlPassENV, PerlSetENV, SetENV etc. I even use PerlPostConfigRequire /path/to/conf/startup.pl Why is it I can;t see a full ENV? Any pointers would be great. CIA -ants - What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship.
Re: Which template engine is best to create a perl site
hi, On Wed, 6 Jun 2007, Perrin Harkins wrote: On 6/6/07, Octavian Rasnita <[EMAIL PROTECTED]> wrote: > I have tested HTML::Template::JIT, but HTML::Template::Compiled was much > faster than it. Sorry, but I suspect there's a mistake in your test. Possibly you counted the time for JIT to do the initial compile, which is slow but only happens once. HTML::Template::Compiled is fast, but it's not as fast as JIT. well, in my tests (i'm the author of HT::Compiled, so of course i will advertize it =) it was faster in some cases than JIT (e.g. if the template was big enough). and yes, i mean faster *after* the initial compilation. it's also a bit faster than H::T::Pro (but only in the best case, case_sensitive and with memory cache). (i commented out JIT of my benchmark script, though, because it generated errors someday and didn't stop. also i realized that it changed the $_ variable after the run.) harder to debug template coding mistakes with, and HTML::Template is fast enough. well, many people say, why optimize code if the database is slow anyway. i don't like that. if you can optimize by using a fast module - why not? and by the way, JIT doesn't have many features, while HT::Compiled has the dot syntax. use the examples/bench.pl included in the distribution to see some benchmark results. for example i have used HTC in a cronjob which generated XML - instead of LibXML. before the cronjob took so long that we could just run it 4 times a day. after that it could be run 6 times a day. keep in mind, i'm the author. i'm a fan =) just my 2 cents tina
Re: Which template engine is best to create a perl site
hi, On Wed, 6 Jun 2007, Octavian Rasnita wrote: I don't use HTML::Template::Compiled though, because I found some bugs in it. well it was beta at that time, and it's actually still marked as beta on cpan. you started to use the module really early. now the biggest bugs have been fixed, and i know a few people who use it in production. sure, there might still be bugs waiting; i find it a complex module because it's generating perl code and caching it on disc, so testing all cases is pretty challenging; but i hope that the worst bugs are now fixed. the feature i need most is the dot notation. if you just need that, you might use the dot plugin HTML::Template::Plugin::Dot. this, though, is not as fast.
Re: Which template engine is best to create a perl site
I ran some tests myself to compare the two about 6 months ago. It was a "real world" test (an average sized template from my project), and I did not count the compilation time for the JIT files. The difference between HTML::Template::JIT and HTML::Template::Compiled was very small; smaller than the margin of error. Both of them were twice as fast as HTML::Template with caching enabled, and about two and a half times faster than HT without caching. I decided to use Compiled, because setting up correct file permissions for JIT to work was a real pain, and JIT is very slow compiling for the first request. - Original Message - From: "Octavian Rasnita" <[EMAIL PROTECTED]> To: "Perrin Harkins" <[EMAIL PROTECTED]> Cc: "Clinton Gormley" <[EMAIL PROTECTED]>; "Michael Greenish" <[EMAIL PROTECTED]>; "abhishek jain" <[EMAIL PROTECTED]>; Sent: Wednesday, June 06, 2007 8:40 AM Subject: Re: Which template engine is best to create a perl site From: "Perrin Harkins" <[EMAIL PROTECTED]> Sorry, but I suspect there's a mistake in your test. Possibly you counted the time for JIT to do the initial compile, which is slow but only happens once. HTML::Template::Compiled is fast, but it's not as fast as JIT. I don't recommend actually using JIT though, since it's harder to debug template coding mistakes with, and HTML::Template is fast enough. - Perrin I have made the test using Apache's ab program, in a program that uses mod_perl, and the pages were displayed much more faster when using HTML::Template::Compiled. This happened 3 or 4 years ago if I remember well, and the things might have changed since then. Octavian
Re: Which template engine is best to create a perl site
On Jun 6, 2007, at 10:34 AM, Tina Müller wrote: well, many people say, why optimize code if the database is slow anyway. i don't like that. if you can optimize by using a fast module - why not? and by the way, JIT doesn't have many features, while HT::Compiled has the dot syntax. Well with this sort of system, it makes sense to optimize the code -- either way you're using the same templates. Easy choice. But simply choosing 'the fastest' templating system isn't always the best idea -- it can ,and often does, lock you into a templating system that can be extremely hard to migrate from in the future. I'm not a fan of disregarding db blocking when you optimize -- you should always go for the best/fastest possible route. When i looked at Petal, which was slower than many of the other engines, the speed difference was rendered negliblle when measured against the db blocking. i could have chosen a faster engine, but the speed wouldn't have mattered much in context, and I wouldn't have the portability that Petal offered me. So i went with petal, then optimized elsewhere. // Jonathan Vanasco | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | CEO/Founder SyndiClick Networks | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | FindMeOn.com - The cure for Multiple Web Personality Disorder | Web Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | RoadSound.com - Tools For Bands, Stuff For Fans | Collaborative Online Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: Which template engine is best to create a perl site
Sorry, but I suspect there's a mistake in your test. Possibly you counted the time for JIT to do the initial compile, which is slow but only happens once. HTML::Template::Compiled is fast, but it's not as fast as JIT. I don't recommend actually using JIT though, since it's harder to debug template coding mistakes with, and HTML::Template is fast enough. Just want to add: faster if you cache the template.
Re: Which template engine is best to create a perl site
On 6/6/07, Tina Müller <[EMAIL PROTECTED]> wrote: well, many people say, why optimize code if the database is slow anyway. No offense, but those people are entirely correct. Choosing a template module because of its speed when your application is constrained by your database doesn't make sense. None of the popular template modules are slow at this point. and by the way, JIT doesn't have many features, while HT::Compiled has the dot syntax. Now those are good reasons to choose a templating module. And again, I wouldn't recommend using JIT for anything serious unless you're prepared to put some work into it. for example i have used HTC in a cronjob which generated XML - instead of LibXML. before the cronjob took so long that we could just run it 4 times a day. after that it could be run 6 times a day. It sounds like templating (or whatever you would call LibXML) was a major bottleneck for that application then. That's when it makes sense to consider the speed of the templating modules. - Perrin
