Re: another article on perl.com
clayton cottingham [EMAIL PROTECTED] wrote: what about slashdot and perlmonks? When I finish reading the Mod_perl Developer's Cookbook, I was planning on writing a review and submitting it to slashdot (presuming no one beats me to it). I'm not calling dibs or anything, just making a promise that I'll do it if no one else does.
Re: [OT] Re: mod_perl Developer's Cookbook (and Amazon)
Paul Lindner [EMAIL PROTECTED] wrote: I'm against frivolous patents myself. It harms the industry and could even be detrimental to mod_perl or Apache if either is found to infringe upon such a patent. That indeed is the problem. Now that the FTC has been scared (or bought?) off, this is the *obvious* move for a large company to try and cut off the air supply of the open source movement. However, please read the following articles before you boycott. The first is an open letter from Jeff Bezos, the second is a fairly lengthy article on the subject by Tim O'Reilly. http://www.amazon.com/exec/obidos/subst/misc/patents.html http://www.oreilly.com/ask_tim/patent_reform_0300.html I read them some time ago, and re-read them again, and I'm still not impressed. Many companies take out software patents, but they claim they're for defensive purposes, so that they can use them to counter-sue. Amazon is the first case I've heard of where someone used them offensively. Jeff Bezos, to my ear, is just making some noises to put the crowd to sleep. He promises to chat with some congressman and that makes it all better? To me the whole point of boycotts is to provide some pressure to behave ethically even when it's not (yet?) legally mandated. Mike808 [EMAIL PROTECTED] wrote: And Barnes and Noble deserves its fair share of disgust for filing counter patent-infringement suits. I'm no fan of Barnes and Noble, but a counter-suit is a counter-suit... the other guy was already playing dirty, before they started in with it. And since BN owns Fatbrain, Yeah, I know, and am not happy about it, but at least it puts a dollar into the pocket of Amazons victim. so BookPool is my vendor of choice currently for price-conscious book shopping. Thanks, I'll look into that one.
Re: mod_perl Developer's Cookbook
Ask Bjoern Hansen [EMAIL PROTECTED] wrote: On Thu, 31 Jan 2002, Paul Lindner wrote: I won't deal with amazon: http://www.noamazon.com I just added a page with direct links for eight other bookstores. It's now available at http://www.modperlcookbook.org/order.html Amazon are the cheapest though: http://www.allbookstores.com/book/compare/0672322404 Spend only $4 more, and you too can show your disgust for software patents. :-) ?
Re: mod_perl Developer's Cookbook
___cliff rayman___ [EMAIL PROTECTED] wrote: ordered my today through the website (puts a little extra money in the hands of mod_perlers: http://www.modperlcookbook.org/ I just ordered mine through fatbrain, myself, I won't deal with amazon: http://www.noamazon.com If there's a mod_perl developer's fund I could contribute to (like YAS), I'd be glad to send them a check.
[OT] Re: Multiple Sites
Andy Sharp [EMAIL PROTECTED] wrote: As others have aluded to, if you're trying to serve multiple domains (or hostnames) off one IP, you use a system called software virtual hosting. HTTP/1.1 Supports the Host: field in the http header to resolve to the site domain. There's a limitation on virtual hosts though, if you want to do any kind of ecommerce stuff with SSL (which works via the IP number), it won't work if you try to do it with more than one of the vhosts. So you're clients are going to be stuck using an external agency (like paypal?) if they want to take on-line payments. (Though, it's always seemed to me that it might be a decent design to have *one* vhost dedicated to accepting payments for the other vhosts... so when the user is ready to close the deal they get kicked to payment.super_secure.com where they're asked for the credit card info to finish processing).
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 02:28 PM 10/23/2001 -0400, Perrin Harkins wrote: Stephen Adkins wrote: If no one suggests an appropriate list, I propose starting a p2ee group Can I just say that P2EE is a horrible, horrible name? It includes the Java version number (when is J3EE coming out?), as well as Sun's desperate attempt to make it sound like something you buy (Edition) rather than simply a collection of APIs. Something simple, like Perl Enterprise Project or Perl Enterprise APIs makes more sense to me. Several of you have made the same good point. And now the naming flame war has already begun... ;-) Unless there is violent opposition, the name will be Perl Enterprise Framework I would rather name it after the outcome (Framework) than the process (Project). PEP is a much better acronym though. No more Java beans: use PEP pills!
Re: Fast DB access
[EMAIL PROTECTED] wrote: Matthew Kennedy wrote: I'm on several postgresql mailing lists and couldn't find a recent post from you complaining about 6.5.3 performance problems (not even by an archive search). Your benchmark is worthless until you try postgresql 7.1. There have been two major releases of postgresql since 6.5.x (ie. 7.0 and 7.1) and several minor ones over a total of 2-3 years. It's no secret that they have tremendous performance improvements over 6.5.x. So why did you benchmark 6.5.x? This is a good comparison of MySQL and PostgreSQL 7.0: "Open Source Databases: As The Tables Turn" -- http://www.phpbuilder.com/columns/tim20001112.php3 We haven't tried this one. We are doing a project on mysql. Our preliminary assessment is, it's a shocker. They justify not having commit and rollback!! Makes us think whether they are even lower end than MS-Access. Again, checkout PostgreSQL 7.1 -- I believe "commit" and "rollback" (as you put it) are available. BTW, I would like to see that comment about MS-Access posted to pgsql-general... I dare ya. :P You can scale any of these databases; Oracle, MySQL or PostgreSQL, but please research each one thoroughly and tune it properly before you do your benchmarking. I have a different proposal, why don't you do default installations and avoid tuning any of them? If you're going to benchmark something, benchmark what people are actually using. And, again, MySQL does support transactions now. Actually, what they did is they bolted on another database on the side of MySQL. So if you want transactions, you're really going to be using the Berkley DB, and MySQL's much vaunted speed is presumably out the window.. Such chutzpah for them to have promoted an "atomic operations" paradigm for so long without supporting transactions! But that discussion is moot now. "Chutzpah" is an interesting way of putting it. I've been thinking of them as "slimeballs in the busy of conning webkids into thinking they have a real RDBM product". (It isn't a moot point, because it's the same people working on it: human character issues are actually relevant when making technical decisions.) Please be advised that MySQL is threaded and must be tuned properly to handle many concurrent users on Linux. See the docs at http://www.mysql.com That's a good idea. They wouldn't lie to you again, would they? The author of the PHP Builder column did not do his research, so his results for MySQL on Linux are way off. Happily, though, even he got some decent results from PostgreSQL 7.0. Hm, Great Bridge ran industry standard benchmarks of mysql and postgresql, and found that postgresql was faster even on the read-only tests that are supposed to be MySql's bread-and-butter. But I think the Mysql guys said that that was a "tuning" problem also.
Re: [OT] unsubscribing was Re: Varaible scope memory under mod_perl
[EMAIL PROTECTED] wrote: I really don't see the point in putting list info in the headers. The people that have to ask these questions usually don't have full headers turned on. Why not put it at the bottom of each email instead of the headers like some other lists do? It would take up the same amount of space, and it would eliminate the 'how do I unsubscribe' and 'uuugh...see headers' emails. Well actually, it doesn't eliminate those messages. It does make them more amusing, however.
mod_perl, Apache:DB and emacs
I was just playing around a bit with running the perl debugger with mod_perl, as described in the guide: http://perl.apache.org/guide/debug.html#Interactive_mod_perl_Debugging And while I see that there's a tweak described to use ptkdb.pm, I don't see any information on how to get it to use the emacs debugger frontend. Has anyone here done this? Got any hints?
Re: Trouble setting up mod_perl and name-based virtual hosts
"Kyle Dawkins" [EMAIL PROTECTED] wrote: "Joe Brenner" [EMAIL PROTECTED] wrote: I've run into problems adding virtual hosts to a machine where I've already got mod_perl working, but I'm having some trouble pinning it down, because apache just seems to die silently without giving me any hints in the error_log. It definitely does have something to do with an interaction with mod_perl though, because if I comment out "AddModule mod_perl.c" I can at least get apache to restart (though I guess whether the vhosts are working is another question). Does anyone out there have some sucessful examples of httpd.conf files for mod_perl+vhost sites that they can point me at? (Sorry if the answer to this one is out there somewhere, but I've been looking and having found it.) (I'm running a RedHat 6.1 linux system, using perl 5.05, mod_perl 1.21, and apache 1.3.9): Your problem is with the RPMs that you're using (I bet). I am guessing you're using the pre-built ones that come with RH6.1, right? Don't be fooled... these are buggy. Well, you're quite right that I've been trying to stick to the rpms. In many cases they're the ones that came with RH 6.1, in other cases I downloaded newer ones... I guess I'll have to think about just building from source. Doesn't seem like it can hurt. (It occurs to me that I'm also using mod_perl as a DSO... it seemed to me like that was working fine, I wondered a bit why some people thought it was a bad idea. Maybe I've found out why...?) You solution is extremely simple and will only take a short time if you follow the instructions: 1. Use "rpm -e" to remove mod_perl and mod_php, then remove apache. 2. DOWNLOAD THE SOURCES for Apache 1.3.12 and mod_perl 1.24 3. Build them from the source tarballs. You probably want to enable "EVERYTHING" when you build mod_perl. Make sure you build a new apache executable with mod_perl statically linked in. This apache executable takes a bit more RAM but it's faster and way more stable. 4. To make sure that your new httpd has mod_perl built in, execute httpd -l and it should list its modules. If mod_perl appears, you're golden. 5. Remove all the LoadModule and AddModule stuff from your httpd.conf, restart apache, and if it doesn't work, I'd be very surprised... I had the same problem as you (although it was LinuxPPC2000). Oh yeah, I'm just running i386 stuff on a oldish Pentium. It's a bad habit to fall into, not to mention that... As did many others in the past (do a search for "SIGSEGV" or "core dump" or "segmentation fault" in the mailing list archives...), and it's a bummer of a bug because it doesn't bite you until you try something slightly difficult (uh, like "PerlModule Apache::DBI") and it explodes.
