Re: mod_perl advocacy project resurrection
At 01:45 PM 12/10/00 -0800, [EMAIL PROTECTED] wrote: On Sun, 10 Dec 2000, Gunther Birznieks wrote: [much stuff snipped] Things I would never even try with java: 1) Talking any client/server protocol other than URLs. The perl mail/ftp modules are so easy to use and they work great. I don't even want to think about writing to syslogd from inside java... :) There have been public domain libraries to write to syslogd in Java for a long time. The only problem with Java in this regard is that there is no CPAN. But if you search on the net, you can usually find something in Java that has the equivalent to a CPAN module that deals with networking as Java makes networking quite easy. Sun was not onto community thing anyways, they're corporation, and giving up a control something they spend money on, will give chills to the managing types that are not for the OS thing. No CPAN is an oversight for the Java people, but really how can they implement it? Java runs across many platforms and VMs for it are written by many companies. If one dares to do something like that. For one they have to figure out how not to breach security of systems where people will be installing custom java classes. Java like windows2000 was touted for the security and CPAN like thing will bring some bugs and holes into the frame work I am almost sure. Well, with Java, because the modules are not compiled, you don't really need CPAN in the sense of a perl Makefile.pl style. I was really referring to a central repository of code period. There are Java "directories" but nothing like CPAN. I am disappointed at things like gamelan because whenever I want to find something (Ill pick on Gamelan specifically here) (A) Gamelan is slow (B) It's really hard to search on package categories (C) The code points to someone else's website... so it's at the whim of the author still being around. Worse, 75% of the links seem to lead to commercial or shareware sites that gladly take your money if you want to use the class library. I don't think that a CPAN for Java is a security issue any more so than CPAN. It just would be nice to at least have a searchable directory of open source Java libraries. As for SUN not wanting a CPAN, I dont think thats true. They would love to see people writing more open source on top of Java. That doesn't mean that Java itself would be distributed there, but certainly non JDK originated stuff could go into a central directory. Later, Gunther
Re: mod_perl advocacy project resurrection
On Sun, 10 Dec 2000, Jim Woodgate wrote: [EMAIL PROTECTED] writes: You can do the twostage server if you are short on memory, speed is important and usage of active content is relatively low. Setup a mod_proxy and stripped down apache for port 80 and mod_perl for port 8080 for example. Proxy certain urls to the 8080 and you are good. Set low number for the mod_perl items, to avoid thrashing. I'd see where Java is weak, integration wise like 2 MB per process and not even integrated string processing. I'm sorry I wasn't more clear in my first response. My main point was not that the common threads I've seen on this mailing list didn't have good solutions. It was that these things come up alot, and although there are good solutions, they typically involve something beyond mod_perl... I've used dbm files and shared memory before, and I find it easier to use the built in thread support in java (like I said IMHO of course :) Except that won't scale beyond 1 server... -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: mod_perl advocacy project resurrection
At 10:07 AM 12/11/2000 +, Matt Sergeant wrote: On Sun, 10 Dec 2000, Jim Woodgate wrote: [EMAIL PROTECTED] writes: You can do the twostage server if you are short on memory, speed is important and usage of active content is relatively low. Setup a mod_proxy and stripped down apache for port 80 and mod_perl for port 8080 for example. Proxy certain urls to the 8080 and you are good. Set low number for the mod_perl items, to avoid thrashing. I'd see where Java is weak, integration wise like 2 MB per process and not even integrated string processing. I'm sorry I wasn't more clear in my first response. My main point was not that the common threads I've seen on this mailing list didn't have good solutions. It was that these things come up alot, and although there are good solutions, they typically involve something beyond mod_perl... I've used dbm files and shared memory before, and I find it easier to use the built in thread support in java (like I said IMHO of course :) Except that won't scale beyond 1 server... But that's the same thing with IPC shared mem modules yet people still use them on mod_perl for various tricks. It's still easier in Java to do that sort of sharing -- at least it is for me. As always, other people's mileage may vary.
Re: mod_perl advocacy project resurrection
On Mon, 11 Dec 2000, Gunther Birznieks wrote: Except that won't scale beyond 1 server... But that's the same thing with IPC shared mem modules yet people still use them on mod_perl for various tricks. It's still easier in Java to do that sort of sharing -- at least it is for me. As always, other people's mileage may vary. I don't disagree with you. I wish it were easier in Perl too. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: mod_perl advocacy project resurrection
Matt Sergeant writes: Except that won't scale beyond 1 server... If I needed to go beyond one server in java, I would probably look at something like Objectspace Voyager, which is the easiest to use orb I've ever seen. Is there anything similar in perl? I'd love to try it out! -- [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
At 10:51 AM 12/8/00 -0800, Paul wrote: --- Nathan Torkington [EMAIL PROTECTED] wrote: [snip] I'd rather see us find some way to churn out perl and mod_perl programmers. For instance, release a beginner class on Perl and mod_perl and have local Perlmongers lead classes. I have my slides from the University of Perl, which I'd contribute to such an effort (they're pretty closely based around the Eagle book, and some of the details should be replaced with sections on Mason et al.). Makes sense. How do we drum up business? Yup. I think we can come up with good course material, but then it's an issue of marketing. You can lead a programmer to mod_perl, but you can't make him take the course. I went to a local traning firm and offered to teach classes on Perl. The coordinators immediate (and breathlessly excited) response was "Do you teach Java?" Grrr. Well, there is clearly a demand for Java training because Sun never seems to have a shortage of local classes in any major city. And specialized trainers like Bruce Eckel (he is Java's answer to StoneHenge for Perl) seem to be able to offer no end of traveling courses including those based on J2EE Interestingly, I recall sitting in on one of Bruce's courses at Web98 (We were teaching CGI/Perl for a day and he was teaching Intensive Java the day before)... Bruce said he has tried to learn Perl but just couldn't wrap his head around it. I could do Perl classes, for beginners to code or hardened veterans of most other languages (yes, even C++ ;o) I don't think I know enough yet to take people's money for mod_perl or Apache in general, but I don't *want* to teach Java. What should I do do convince people that Perl is a Good Thing? Hmm. My belief is that trainers used to offer Perl. When I lived in the Washington DC area I was always getting pamphlets about Perl and Adv Perl weeklong courses several years ago. (Or perhaps they knew something about my Perl coding...:)) So I am guessing such local trainings aren't offered as much anymore? I think the problem for local training institutes is that they will offer whatever the customer wants. If the customer doesn't want Perl then that's the root of the problem. Unfortunately, the customer paying for the course may be a CIO who has to justify the training cost to to his mgmt who may only be hyped on Java as well. Maybe if we offered suitcase classes on sites like monster.com? Perhaps it is we who should sacrifice ourselves to become managers such that we force Perl upon the programmers coming into our departments just as they, the managers of today, force Java down. Viva La Revolution! :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
Gunther Birznieks [EMAIL PROTECTED] writes: Interestingly, I recall sitting in on one of Bruce's courses at Web98 (We were teaching CGI/Perl for a day and he was teaching Intensive Java the day before)... Bruce said he has tried to learn Perl but just couldn't wrap his head around it. If Damian Conway can do it... ;-) Perhaps it is we who should sacrifice ourselves to become managers such that we force Perl upon the programmers coming into our departments just as they, the managers of today, force Java down. Viva La Revolution! Hopefully, I'm going to be in exactly this position. I've got a few "web programmers" to hire but I want all of them to be throughly bootcamped in "the Unix Way" and Perl, whatever Cold Fusion and Java magic they ultimately get involved with. -- 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 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
At 09:27 AM 12/6/00 +, Matt Sergeant wrote: On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: I haven't looked at AO or AxKit, but if I can untar either one of them and just get to work, that will rule. You can't, but thats because I believe in the CPAN model - use pre-written components. I don't believe shipping all those components in AxKit (and there are a fair number required) is the right solution. Maybe I'm mistaken. I think you are right for AxKit. I assume some modules you depend on are compiled (eg XML::Parser). If this is the case, then it's a pain in the ass to manage distributing all the modules together. And since you rely on mod_perl, you already assume a certain level of expertise that your users have. However, in our toolkit, we do ship CPAN modules with it. But this is only for modules that don't require compilation and because we want someone who downloads our apps to run it on any web server out there -- no dependencies. Yet, if there is mod_perl, the apps will run fast. So I think both models are appropriate. And I believe you are right to distribute AxKit the way you do. Later, Gunther - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
At 12:06 AM 12/6/00 -0600, Jim Woodgate wrote: Chris Winters writes: Along with the open-source Servlet/JSP/Web Engine servers (among others): Apache Tomcat: http://jakarta.apache.org/ Jetty: http://jetty.mortbay.com/ I'm currently using the Tomcat at work, and I have to say that although I really love perl and mod_perl, there are real advantages to using java. Over the past couple of years that I've been mostly lurking on this list there have been a couple common threads: 1) Memory Usage: embedding the perl interpreter on every process uses lots of memory. This of course can be tweaked and isn't as bad on good OS's, but it is a common thread. 2) Sharing information between the processes. There's lots of different ways to do it, but none really jumps out as an end-all solution. With a system like Tomcat running in a jvm outside of apache, you only have one jvm, and you get things like being able to share a cache between all sessions alot easier. I personally find the configuration of mod_perl to be more straight forward than Tomcat, but I do see some advantages to that system (I'm sure there are some speed disadvantages to the tomcat communcation, but haven't done any benchmarks). That being said, I wonder how difficult it would be pull the perl intepreter out of mod_perl and run a perl stand-alone multi-threaded daemon which listens for mod_perl api calls... :) This is very similar to SpeedyCGI + mod_speedy. Although it's more like a servlet engine model than actually get access to Apache API. SpeedyCGI is not web server specific (except the mod_speedy module). Things I would never even try with java: 1) Talking any client/server protocol other than URLs. The perl mail/ftp modules are so easy to use and they work great. I don't even want to think about writing to syslogd from inside java... :) There have been public domain libraries to write to syslogd in Java for a long time. The only problem with Java in this regard is that there is no CPAN. But if you search on the net, you can usually find something in Java that has the equivalent to a CPAN module that deals with networking as Java makes networking quite easy. 2) Spawning an external process. I try not do it in mod_perl, but I have never been able to pull it off in java. I don't see why you are having a problem. We do it all the time for utilities we don't have any other access to. Later, Gunther - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
At 08:26 PM 12/5/00 +, Matt Sergeant wrote: On Tue, 5 Dec 2000, Eric Strovink wrote: A number of people have been beating around this bush, so why not just mow it down? A huge win for advocacy would be a small set of complete example applications targetted at, say, the last two RedHat distros. Each application should install itself -- .conf files, .htaccess files, dbm's, directory structures, perl code, html and templates, correct version of Perl, CPAN packages for any stuff needed, Apache, mod_perl, mod_ssl, mod_whatever, mysql, database schemas, database contents, DBI, Session, front-end proxy -- everything. Each application should gronk whatever's already there, or rename it out of the way. Warnings in big letters. Tough doots. Do you have any idea how hard this is? Seriously. Because I do. Dave Rolsky does. And doing this for free is going to be nigh on impossible. Each application package should contain dumbed-down documentation that explains what it does, and how it does it. Good writers are really hard to come by. Good writing is also quite time consuming to do. Arguably even more so than coding when you take into account drawing diagrams and testing the writing/instructions. I don't want to poo-poo on the idea by any means, the *idea* itself is fine, but the implementation of it is non-trivial. I agree. Huge binary distribution might be nice (similar to the Win32 Apache Mod_Perl binary) but it is fraught with a lot of work. I think there are ways to make the Apache/mod_perl install easier which perhaps should be more the focus instead. Things I'd like to see: 1) mod_perl problems with DSO solved. DSO would make it easy to compile one apache and then install mod_perl as a separate RPM. 2) shell scripts that do some introspection on how Apache was compiled in the first place and creates a shell script to do the final compilation instead of having to guess all the cmdline params. #2 is not easy, but I think there are heuristics that could certainly help. At the very least a sample shell script to go along with each type of install with commented out params would help provide a simple example. Then the user could selectively delete the comments if they want that cmd line parameter. I find installing mod_perl when I haven't done it in months very annoying because I have to keep hunting around readme's to discover the cmdlines that I used. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
At 09:13 PM 12/5/00 +0100, you wrote: On Tue, 5 Dec 2000, Eric Strovink wrote: A number of people have been beating around this bush, so why not just mow it down? A huge win for advocacy would be a small set of complete example applications targetted at, say, the last two RedHat distros. Each application should install itself -- .conf files, .htaccess files, dbm's, directory structures, perl code, html and templates, correct version of Perl, CPAN packages for any stuff needed, Apache, mod_perl, mod_ssl, mod_whatever, mysql, database schemas, database contents, DBI, Session, front-end proxy -- everything. Each application should gronk whatever's already there, or rename it out of the way. Warnings in big letters. Tough doots. Each application package should contain dumbed-down documentation that explains what it does, and how it does it. The idea would be to put into people's hands several different complete, debugged, sophisticated frameworks for building the rest of their application. All the hard stuff's done -- .conf, proxying, DBI, session control, cookies, templating, compiling, building, and so on. All the newbie has to do is tweak an already-working example, without necessarily understanding all of what s/he's been given. Sounds like a good project fore Xtropia.com... Gunther? We already do this for CGI/flatfile distribution. I suppose we could experiment with making a mod_perl,mySQL optimized solution for our stuff. I have an intern who could probably make this work within the next couple of months. I don't think I would do more by making a binary mySQL/Apache/mod_perl distro along with our apps though. That's too much of a can of worms. Later, Gunther - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
I don't mean to naysay it, but this is going to start getting quite binary specific. I guess you could maintain an RPM for Linux, but beyond that it seems quite difficult. And even if you maintain it as an RPM for Linux, do you make your own Perl distro with it or use RedHat's crappy distro? Or? On Linux I think installing Apache with Mod_Perl is almost trivial. What might be needed is some shell scripts that automate the process to accompany the readme's. It's the other platforms that are a bear for me personally. But if you made a binary for every platform. Wah! So hard. I think you are better off not touching the binary stuff and sticking to writing a traditional app framework that is not dependent on mod_perl, is not dependent on any database, but can make use of such things. Then, people can upgrade as they see fit. Later, Gunther At 03:54 PM 12/6/00 -0500, Aaron E. Ross wrote: at a time earlier than now, Dave Rolsky wrote: On Wed, 6 Dec 2000, brian moseley wrote: But I'd also like to point out, as Matt Sergeant said, this stuff is _really_ hard, and not very glamorous. I would've done much less of it while the install and auto configure part is not very glamorous, the possibility of being able to untar one package to get mod_perl w/ persistent db connections, transaction management, data relational modeling/objects and a nice templating/servlet engine is very glamorous! you could be a folk hero! honestly it seems like a pretty worthwhile project to me. basically, what is missing is (cough! cough!) simply a lot of hard work. except for transaction management, which is apparently of questionable value, all the pieces exist, right? database abstraction and connection pooling = DBI session management = Apache::Session load balancing = mod_backhand?? data relational mapping = Tangram or Alzabo templates or whatever you want to call them = HTML::Embperl/Mason/TemplateToolkit ide = pick an editor with a few hooks to call make, install and restart granted this may not get us everything, but if we could package up the stuff we all use over and over again, wouldn't that get us pretty far? Aaron I'm willing to contribute time to this project if given some input on how to proceed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
At 01:05 PM 12/5/00 -0600, Jay Jacobs wrote: On Tue, 5 Dec 2000, Stas Bekman wrote: What we want is very simple. 1. We want many users, so they will thoroughly test the software and spot bugs asap, so we -- current users will get a better product. 2. We want more developers, so they will write core mod_perl and 3rd party modules, again for us current users to re-use and save development time. The first item is directly linked to the second, as new developers come out from users. I think a good first step in that direction is to have mod_perl modules to do some of the basic things that early web developers want... a few really well documented and tailored-for-newbies modules. I think back a few years to "Matt's Script Archive", and what that did for perl and CGI. (Anyone for Apache::Formmail?) Just some stuff to get the new developer interesting in figuring out how to compile mod_perl, and to see the benefits of it. It could even be done with step-by-step examples, with gradually increasing functions. ( "Now move on to Guestbook-DBI" ... "Now add in Apache::Session for such-n-such functions" ) Perhaps even offer the same modules under mason, embperl axkit, etc. so folks can take a step in those directions too. I think this is what the Eagle book does really. But within your idea, I would advocate more standalone applpications. It so happens that the guestbook we distribute on eXtropia supports flatfiles on mod_perl but if you want, you can graduate it to a DBI version that works with mod_perl. I just think back to the time when I started putting smarts-to-web and these were the first steps I took, and I looked for that kind of hand holding as I figured out how to make it work. I think this makes sense. I could also see Apache::FormMail being interesting if it was written from an ISP perspective (giving users a form mail that can be used by any server). BTW, our WebResponder app (Basically same as Matt Wright's Form Mail) works with mod_perl too. Same as our WebDB and our WebCalendar. Later, Gunther - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
At 02:01 PM 12/6/00 -0800, brian moseley wrote: On Wed, 6 Dec 2000, Aaron E. Ross wrote: while the install and auto configure part is not very glamorous, the possibility of being able to untar one package to get mod_perl w/ persistent db connections, transaction management, data relational modeling/objects and a nice templating/servlet engine is very glamorous! you could be a folk hero! honestly it seems like a pretty worthwhile project to me. basically, what is missing is (cough! cough!) simply a lot of hard work. except for transaction management, which is apparently of questionable value, all the pieces exist, right? database abstraction and connection pooling = DBI session management= Apache::Session load balancing= mod_backhand?? data relational mapping = Tangram or Alzabo templates or whatever you want to call them = HTML::Embperl/Mason/TemplateToolkit ide = pick an editor with a few hooks to call make, install and restart granted this may not get us everything, but if we could package up the stuff we all use over and over again, wouldn't that get us pretty far? Aaron I'm willing to contribute time to this project if given some input on how to proceed. perhaps take a look at AO - it's a good start at a servlet engine that packages at least a few of the items you've highlighted. i'd love to participate in a project that uses AO, backhand, an o/r mapping tool, and other components to provide an out of the box 2-tier system. i'd also love to see an "enterprise" or 3-tier version of same. let's organize! i suppose i should get the AO sourceforge site up and running eh? To be fair with regards to application toolkits, there's also SmartWorker.org and our eXtropia stuff. :) We already have 3-tier solutions working on our apps using SOAP as the primary marshalling protocol acting as a proxy to Java versions of our objects. This allows us to do intelligent database and rowset result caching on a multithreaded Java server while the front-end Perl apps just marshall calls in to that server using SOAP. I do wish there were more app toolkits out there as it would create more choice and provide some good experiments about what's a good mechanism for developing apps. eg I found looking at SmartWorker very interesting to see what I liked and did not like and Microsoft ASP for what I liked and didn't like. Of course, I disliked most of Microsoft ASP, but I did like ADO, so we stole the concept and implemented it in Perl and Java (JDO is still not out yet officially from JavaSoft). Of course, app toolkits are tough to write, and then you have to write or find people to write real apps on top of them to validate the design work. Later, Gunther - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
[EMAIL PROTECTED] writes: You can do the twostage server if you are short on memory, speed is important and usage of active content is relatively low. Setup a mod_proxy and stripped down apache for port 80 and mod_perl for port 8080 for example. Proxy certain urls to the 8080 and you are good. Set low number for the mod_perl items, to avoid thrashing. I'd see where Java is weak, integration wise like 2 MB per process and not even integrated string processing. I'm sorry I wasn't more clear in my first response. My main point was not that the common threads I've seen on this mailing list didn't have good solutions. It was that these things come up alot, and although there are good solutions, they typically involve something beyond mod_perl... I've used dbm files and shared memory before, and I find it easier to use the built in thread support in java (like I said IMHO of course :) So is with FastCGI, reinventing the wheel man is not a good thing. Sun people are on this thing to rewrite the world and put a Sun stamp on it and make everybody use it. Whahoo. Never looked at FastCGI, does it allow the request to query the server while it is running, or is it more like a call to an external server than get a response? Also, if there are multiple processes running I don't see how that is any better than mod_perl with a proxy for static pages? I would also agree that for things that require hooks into the apache api, mod_perl can do things that just can't be done with the other systems. I was simply playing devil's advocate in pointing out that common themes on this list are non-problems with some other solutions, and if we're talking advocacy, these issues might come up... -- [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Sun, 10 Dec 2000, Gunther Birznieks wrote: I'm currently using the Tomcat at work, and I have to say that although I really love perl and mod_perl, there are real advantages to using java. Over the past couple of years that I've been mostly lurking on this list there have been a couple common threads: 1) Memory Usage: embedding the perl interpreter on every process uses lots of memory. This of course can be tweaked and isn't as bad on good OS's, but it is a common thread. You can do the twostage server if you are short on memory, speed is important and usage of active content is relatively low. Setup a mod_proxy and stripped down apache for port 80 and mod_perl for port 8080 for example. Proxy certain urls to the 8080 and you are good. Set low number for the mod_perl items, to avoid thrashing. I'd see where Java is weak, integration wise like 2 MB per process and not even integrated string processing. 2) Sharing information between the processes. There's lots of different ways to do it, but none really jumps out as an end-all solution. Java movement has stretched out itself too thin, they did not identify themselves with a particular niche, and so we did it for them, where they don't really excell either - web applets, flash is more fit for that sort of thing. Perl is not very known for doing gui but spreading out knowlege about perl/tk helps. Which is just as good as AWT(? not sure of the name) With a system like Tomcat running in a jvm outside of apache, you only have one jvm, and you get things like being able to share a cache between all sessions alot easier. So is with FastCGI, reinventing the wheel man is not a good thing. Sun people are on this thing to rewrite the world and put a Sun stamp on it and make everybody use it. Whahoo. I personally find the configuration of mod_perl to be more straight forward than Tomcat, but I do see some advantages to that system (I'm sure there are some speed disadvantages to the tomcat communcation, but haven't done any benchmarks). Try FastCGI, it is really fast if you can do multiplexing. Besides the fact, I will write apache C modules if I need speed, not use some unproven languages to handle maximum loads, with lowest response time. That being said, I wonder how difficult it would be pull the perl intepreter out of mod_perl and run a perl stand-alone multi-threaded daemon which listens for mod_perl api calls... :) This is very similar to SpeedyCGI + mod_speedy. Although it's more like a servlet engine model than actually get access to Apache API. SpeedyCGI is not web server specific (except the mod_speedy module). Good one. However would you really get the advantage of performing configuration manipulations on the fly? Or dynamic generation of the configs form templates and lists of values? Things I would never even try with java: 1) Talking any client/server protocol other than URLs. The perl mail/ftp modules are so easy to use and they work great. I don't even want to think about writing to syslogd from inside java... :) There have been public domain libraries to write to syslogd in Java for a long time. The only problem with Java in this regard is that there is no CPAN. But if you search on the net, you can usually find something in Java that has the equivalent to a CPAN module that deals with networking as Java makes networking quite easy. Sun was not onto community thing anyways, they're corporation, and giving up a control something they spend money on, will give chills to the managing types that are not for the OS thing. No CPAN is an oversight for the Java people, but really how can they implement it? Java runs across many platforms and VMs for it are written by many companies. If one dares to do something like that. For one they have to figure out how not to breach security of systems where people will be installing custom java classes. Java like windows2000 was touted for the security and CPAN like thing will bring some bugs and holes into the frame work I am almost sure. happy hacking, pavel
Re: mod_perl advocacy project resurrection
Ask Bjoern Hansen sent the following bits through the ether: Talarian have a Perl API for SmartSockets. I would think they have for their "SmartMQ" thingy too. If not then it's probably easy to make. (rapidly going OT) There's a simple Perl interface to http://www.spread.org/ which works pretty well. Leon -- Leon Brocard.http://www.astray.com/ yapc::Europehttp://yapc.org/Europe/ ... All new improved Brocard, now with Template Toolkit! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
One simple question please. How do you differentiate between perl programmers amd Mod_perl programmers? Thanks Stas Bekman wrote: I've dropped my last job, in order to finally finish the mod_perl book, have some rest and make a push to mod_perl. Well best of luck hope you have a good rest - I'll certainly buy the book! :) I see two main streams: 1) Online zines. 2) Conferences. I think that we should start working on locating ezines wanting to publish mod_perl related articles (preferrably for a fee, to give incentives for others to write) and conferences where mod_perl can be relevant. The data is to be collected and distributed to the people who wish to advocate mod_perl, thru written articles and conference classes. I suppose that we will also look for companies who want to order mod_perl classes and find the teachers in the appropriate areas. I think may people could write simple "How to ZXY" in mod_perl. PHP has excellent resources for similar things i.e how to do this or that. Very much like the Perl Cookbook. I am not saying that mod_perl does not have these, and the guide has some excellent examples, but these are often not easy to find and will not attact people half as much as reading a single all-in one atricle. Right, so anybody wants to get famous (well at least a little :), you wrote some cool code snippet -- describe the gist, attach the source and let others look over it. Sort of WebTechniques columns by Randal. May be we could organize some certification classes, to give more PR to mod_perl. Not wishing to sound negative - but certification more often causes problems - MCSE's a case in point. well, may be. Obviously we don't need certifications when we cannot find mod_perl programmers at all. I just thought about it as the counter-intuitive solution -- create the certification program and make people think that there are so many mod_perl programmers that we there was a need for a certification -- which will bring to the interest, since people believe that if someone is running certification program it must be good. And then once started to learn Perl/mod_perl he is actually going to realize that it's good indeed. Overall Stas I think more aticles in the general IT press be it ezines or in paper is the way to go to raise the profile. Yeah, but I don't seem to make other interested. I don't know why. Folks are too busy I guess. As an aside whats happening to perl month ? as this appears to be exactly the sort of thing we need. I don't know. Baiju told me back in August that he resumes the functionality but he has dissapeared since then. I'll try to reach him. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Fri, 8 Dec 2000, harilaos wrote: One simple question please. How do you differentiate between perl programmers amd Mod_perl programmers? If you are in a public transportation and you happen to overhear this kind of discussion: "...all children were running and refused to respond. I've tried to killed them but in vain, they refused to die, and were just hanging there. So I've killed their parent and the children have gone for good. Next time I'd know to kill the parent first..." Ask the guys whether they are available, because you have a job for them, but do it discreetly... _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
The mod_perl programmer has no hair left. :) At 11:19 AM 12/8/2000 +, harilaos wrote: One simple question please. How do you differentiate between perl programmers amd Mod_perl programmers? Thanks Stas Bekman wrote: I've dropped my last job, in order to finally finish the mod_perl book, have some rest and make a push to mod_perl. Well best of luck hope you have a good rest - I'll certainly buy the book! :) I see two main streams: 1) Online zines. 2) Conferences. I think that we should start working on locating ezines wanting to publish mod_perl related articles (preferrably for a fee, to give incentives for others to write) and conferences where mod_perl can be relevant. The data is to be collected and distributed to the people who wish to advocate mod_perl, thru written articles and conference classes. I suppose that we will also look for companies who want to order mod_perl classes and find the teachers in the appropriate areas. I think may people could write simple "How to ZXY" in mod_perl. PHP has excellent resources for similar things i.e how to do this or that. Very much like the Perl Cookbook. I am not saying that mod_perl does not have these, and the guide has some excellent examples, but these are often not easy to find and will not attact people half as much as reading a single all-in one atricle. Right, so anybody wants to get famous (well at least a little :), you wrote some cool code snippet -- describe the gist, attach the source and let others look over it. Sort of WebTechniques columns by Randal. May be we could organize some certification classes, to give more PR to mod_perl. Not wishing to sound negative - but certification more often causes problems - MCSE's a case in point. well, may be. Obviously we don't need certifications when we cannot find mod_perl programmers at all. I just thought about it as the counter-intuitive solution -- create the certification program and make people think that there are so many mod_perl programmers that we there was a need for a certification -- which will bring to the interest, since people believe that if someone is running certification program it must be good. And then once started to learn Perl/mod_perl he is actually going to realize that it's good indeed. Overall Stas I think more aticles in the general IT press be it ezines or in paper is the way to go to raise the profile. Yeah, but I don't seem to make other interested. I don't know why. Folks are too busy I guess. As an aside whats happening to perl month ? as this appears to be exactly the sort of thing we need. I don't know. Baiju told me back in August that he resumes the functionality but he has dissapeared since then. I'll try to reach him. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
[EMAIL PROTECTED] wrote: On Thu, 7 Dec 2000, Matt Sergeant wrote: snippage I'd love that. In fact anything that anyone had waiting to go onto PerlMonth please drop a mail to [EMAIL PROTECTED] and we'll get you published. (assuming that PerlMonth isn't going to resurrect itself) Actually its kinda has been resurrected. Or it will be on the upcoming monday. There are a lot of mod_perl articles on PelrMonth and it will continue. Next issue has an article by Stas and Gerald Richter. As far as articles are concerned perlmonth.com has about 20 or so mod_perl related articles. I know I've kinda been absent for some time. And I want to publicly apologize to the readers and the writers. Hurray ! Can I say thanks - I like perl month! Is the HTML::Template part 2 in there ? Is it back for "good" (good = 3 plus months ?) Greg But the next issue will be out upcoming monday. I am also contemplating on starting www.apachemonth.com, and looking for someone to possibly write mod_perl related articles on such topics like, handling different phases of Apache with mod_perl, writing PerlTransHandlers, explanations on *Handlers, stuff that is more closely related to Apache, rather than templating solutions and such, which serve better under PerlMonth. If anyone is interested in that please drop me a line or two. - Baiju Thakkar http://www.perlmonth.comhttp://www.linuxmonth.com Just use Perl; #!/boot/linux - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alliance? WAS - Re: RFC: mod_perl advocacy project resurrection
At 08:13 08/12/2000 +0800, Gunther Birznieks wrote: The could be although ActiveState has a product that competes with mod_perl on the NT side called PerlEx. What is too bad about the silence about the relationship is that PerlEx as a product could really benefit from evolving upon the back of a mod_perl code base. In addition to that, they also have Zope-Perl, which iirc is run for AS by Gisle Aas, who probably knows a lot about mod_perl. Now if AS would support mod_perl, they'd get a very broad range of products for the dynamic server marketplace. That could be a good argument for them support mod_perl. -- robin b. Paranoids are people, too; they have their own problems. It's easy to criticize, but if everybody hated you, you'd be paranoid too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Matthew Kennedy writes: If I were developing an application which fit well into the two-tier model however, a mod_perl based plan would be my first preference -- development time is shorter than JSP/Servlet and maintainability is _at_least_ comparible. I would add that the "java is easier to maintain" issue is IMHO the biggest myth of java. I've seen a bunch of over-engineered java the past couple of years and when something goes wrong, be afraid! :) -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Fri, 8 Dec 2000, Greg Cope wrote: I'd love that. In fact anything that anyone had waiting to go onto PerlMonth please drop a mail to [EMAIL PROTECTED] and we'll get you published. (assuming that PerlMonth isn't going to resurrect itself) Actually its kinda has been resurrected. Or it will be on the upcoming monday. There are a lot of mod_perl articles on PelrMonth and it will continue. Next issue has an article by Stas and Gerald Richter. As far as articles are concerned perlmonth.com has about 20 or so mod_perl related articles. I know I've kinda been absent for some time. And I want to publicly apologize to the readers and the writers. Hurray ! Can I say thanks - I like perl month! You're welcome and Thank you for reading :) Is the HTML::Template part 2 in there ? I had contacted Sam Tregar about 3 weeks ago. I didn't get a respond. It won't be for this issue, but I'll try to get Part 2 for the next issue. Sam, if you're reading this, drop me a note. Is it back for "good" (good = 3 plus months ?) Yes, Definately. - Baiju Thakkar http://www.perlmonth.comhttp://www.linuxmonth.com Just use Perl; #!/boot/linux - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Fri, 8 Dec 2000, Keith G. Murphy wrote: Stas Bekman wrote: Let me stright things out a bit, so you won't get misleaded by my post as a marketing call. What we want is very simple. 1. We want many users, so they will thoroughly test the software and spot bugs asap, so we -- current users will get a better product. 2. We want more developers, so they will write core mod_perl and 3rd party modules, again for us current users to re-use and save development time. [cut] It strikes me that there might be a route not yet taken to increase *availability* of mod_perl. Think about all the ISPs that host personal and small business web sites. How many of them run Apache and allow their customers to code Perl scripts? This route is partially taken. I've addressed these issue in one of the previous articles http://apachetoday.com/news_story.php3?ltsn=2000-11-27-001-01-OS-LF-PL And if you have an ISP that you want to become aware of mod_perl (and learn about problems and solution) please point them to this article. Earthlink (which is huge), for one. Yet it doesn't have mod_perl installed. But if it did, both Earthlink itself and the customers might see performance benefits from Apache::Registry scripting. The two biggest obstacles I see to this: (1) Have to have a *reliable* way for customers to reload their Registry scripts. Here's where some development work might be needed. (2) It might be argued that anything that *needs* Registry is too heavy-duty for the ISP to want it running anyway. Thoughts? (I wonder if it might be possible to enlist the Apache folks to campaign for this as well, since anything that keeps out the dread IIS is desirable). What do you mean by enlisting the Apache folks? When is the demostration :) The real question is for someone to undertake the Safe module and make it working for mod_perl. I think we have discussed this before. I don't remember what was the conclusion. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
--- Nathan Torkington [EMAIL PROTECTED] wrote: [snip] I'd rather see us find some way to churn out perl and mod_perl programmers. For instance, release a beginner class on Perl and mod_perl and have local Perlmongers lead classes. I have my slides from the University of Perl, which I'd contribute to such an effort (they're pretty closely based around the Eagle book, and some of the details should be replaced with sections on Mason et al.). Makes sense. How do we drum up business? I went to a local traning firm and offered to teach classes on Perl. The coordinators immediate (and breathlessly excited) response was "Do you teach Java?" Grrr. I could do Perl classes, for beginners to code or hardened veterans of most other languages (yes, even C++ ;o) I don't think I know enough yet to take people's money for mod_perl or Apache in general, but I don't *want* to teach Java. What should I do do convince people that Perl is a Good Thing? Maybe if we offered suitcase classes on sites like monster.com? __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Fri, 8 Dec 2000, Stas Bekman wrote: The real question is for someone to undertake the Safe module and make it working for mod_perl. I think we have discussed this before. I don't remember what was the conclusion. That its pretty hard to do, and requires Safe holes to be any use for anything serious. Although someone had DBI working through Safe that emailed me, but I've since discarded or lost that email. FWIW, I still have Apache::Safe hanging around here somewhere. Not that its any use though :-) -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [me too] certification [Was: mod_perl advocacy project resurrection]
On Fri, 8 Dec 2000, Paul wrote: I would love to be able to list on my resumé that I was Perl and mod_perl certified. How about publicity in the form of a page listing certified Perl/modPerl coders on take23, with contact info if they like? Great for getting those job offers. We will be doing jobs and resumes on there when I get some tuits to do a bit more coding on the site, maybe over xmas. What I'd love to be able to provide is some sort of auto-matcher for employers/employees, but thats way up there right now. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[me too] certification [Was: mod_perl advocacy project resurrection]
First, the gratuitous "me, too!" As fair warning, there's little more than that in terms of valid content here, but if you're still interested in reading the rest --- "J. J. Horner" [EMAIL PROTECTED] wrote: On Wed, Dec 06, 2000 at 01:22:26PM -0800, Randal L. Schwartz wrote: "Gunther" == Gunther Birznieks [EMAIL PROTECTED] writes: Gunther This is exactly why someone experienced in training (ie Gunther Randal/StoneHenge) would hopefully be the ones to take the Gunther torch on this. If there's anyone I would trust a Gunther certification from, it would be them. We've considered the certification route from time to time, but other than being a money maker for us (which isn't all that bad of a deal :-), I'm still not entirely convinced that the community of *ours* would demand certification in any distinguishing way. I mean, until I can demonstrate that people with certs are likely to get hired faster or make more money, what's the point? As it is now, good mod_perl people are hard enough to find that the jobseeker already has the advantage. I'm very open to being convinced otherwise though. I'd be interested in something like this. For a low price ($50-$100), I would do that. In fact, I would probably pay more. I'd take a list of activities from your website, complete the activities, submit my code back to you, and let you grade me, and then send me some form of certificate saying "Certified mod_perl hacker" with Stonehenge and the famous merlyn signing it. I'd be a little less eager about the sort of simple multiple choice that would be easiest to automate, but even that would suffice. If we could get Doug and Lincoln to sign off on the list of activities, the certification couldn't get more genuine than that. Agreed. [snip] How many technologies have the actual creator as part of the certification process? It could only help. I don't know about "only", but I second the sentiment. I would love to be able to list on my resumé that I was Perl and mod_perl certified. How about publicity in the form of a page listing certified Perl/modPerl coders on take23, with contact info if they like? Great for getting those job offers. __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Stas Bekman wrote: Let me stright things out a bit, so you won't get misleaded by my post as a marketing call. What we want is very simple. 1. We want many users, so they will thoroughly test the software and spot bugs asap, so we -- current users will get a better product. 2. We want more developers, so they will write core mod_perl and 3rd party modules, again for us current users to re-use and save development time. [cut] It strikes me that there might be a route not yet taken to increase *availability* of mod_perl. Think about all the ISPs that host personal and small business web sites. How many of them run Apache and allow their customers to code Perl scripts? Earthlink (which is huge), for one. Yet it doesn't have mod_perl installed. But if it did, both Earthlink itself and the customers might see performance benefits from Apache::Registry scripting. The two biggest obstacles I see to this: (1) Have to have a *reliable* way for customers to reload their Registry scripts. Here's where some development work might be needed. (2) It might be argued that anything that *needs* Registry is too heavy-duty for the ISP to want it running anyway. Thoughts? (I wonder if it might be possible to enlist the Apache folks to campaign for this as well, since anything that keeps out the dread IIS is desirable). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [me too] certification [Was: mod_perl advocacy project resurrection]
On Wed, Dec 06, 2000 at 01:22:26PM -0800, Randal L. Schwartz wrote: I mean, until I can demonstrate that people with certs are likely to get hired faster or make more money, what's the point? As it is now, good mod_perl people are hard enough to find that the jobseeker already has the advantage. "The jobseeker already has the advantage" is the key phrase. I think the general idea is to balance that out and broaden both the job market for mod_perl folks, and the talent pool of mod_perl programmers. At this point, IMO certification is the end of the line, the destination. What we need is a path to the destination. We want to generate enough interest and (dare I say) marketability of mod_perl to warrant certification. Articles are helpful, but when was the last time you saw a corporate big-wig reading TPJ or Perl Month? I'm sure it happens, but what about getting an article in the big trade rags? Slipping something in Ziff-Davis rags, the things that sit on their desk and coffee tables... I'd take a list of activities from your website, complete the activities, submit my code back to you, and let you grade me, snip Copy and paste works wonders in the web. You'd need heavy code-commenting or a detailed explanation from the person (preferably in person) of the code they "wrote". It's the right path, just need to prepare for the lowest common denomenator. I'd be a little less eager about the sort of simple multiple choice that would be easiest to automate, but even that would suffice. Or a good combination thereof. I would love to be able to list on my resumé that I was Perl and mod_perl certified. How about publicity in the form of a page listing certified Perl/modPerl coders on take23, with contact info if they like? Great for getting those job offers. From an employer's standpoint, that's an awful statement to read. If I hire a certified perl/mod_perl person, I'd like to believe that they're with my company, and not reviewing other job offers continually, if the site could evolve to "available certified folks"... that would be a much better solution. See point #1 above. Jay Jacobs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, brian moseley wrote: [...] consider a scenario in which somebody uses a web interface to signal an action, which is placed into a message queue. on the other end of that queue, a service handles the event with a transaction that spans multiple third tier systems. this is the kind of architecture that is begging to be embraced by perl. Talarian have a Perl API for SmartSockets. I would think they have for their "SmartMQ" thingy too. If not then it's probably easy to make. http://www.talarian.com/products/smartsockets/ http://www.talarian.com/products/smartmq/ - ask -- ask bjoern hansen - http://ask.netcetera.dk/ more than 70M impressions per day, http://valueclick.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
Patrick wrote: On Thu, Dec 07, 2000 at 03:52:01PM +0100, Stas Bekman took time to write: Your problem is that you try to use the precompiled broken packages provided by distros. If I can jump... I must say that I *never* had a problem with Debian packages of mod_perl. Maybe RedHat packages have (don't known I don't use that), but Debian packages are correct for me. So on a Debian System, you just need to do : apt-get install libapache-mod-perl and tweak the configuration files. At least that's my experience. Mmmm, I did have a big problem (segfaults) with the apache and mod_perl from Debian 2.1. I think it was an upstream, not package, problem though: that was when most everybody was having a problem with mod_perl as a module. I built it into Apache though, and it worked fine. Debian 2.2 has it built that way as a binary, so I've just gone with that. I've stayed away from the separate module thing, so I have no idea how well it works now. (BTW, kudos the the Debian maintainer which probably reads this list) Absolutely. I've never seen a package problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
Jim Winstead wrote: (of course, this only addresses scaling to a breadth of users, not scaling into the enterprise area. that just requires real marketing and hype.) I saw an article in the Financial Times the other day. Some people have written a "Fax your MP[1]" gateway (http://www.faxyourmp.org/). A quick GET tells us that their server is running php, though I seem to recall (reading about what they did previously) that they did some initial database crunching in Perl. :) The FT wondered why these handful of guys could put this thing together so quickly, when big institutional IT schemes seem to take forever to go nowhere at great cost (paraphrasing slightly). Cheers -- Tim Sweetman A L Digital "How many fates turn around in the overtime?" --- Tori Amos, "The Mythical Man-Month" [1] That's "member of parliament", politician representing your area - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
kyle dawkins [EMAIL PROTECTED] writes: On Wed, 06 Dec 2000 05:52, Matthew Byng-Maddick wrote: 6. Engineering The Perl community is made up of a truly eclectic group of people, which is an amazing strength. However, it's also an amazing weakness: I get the impression that very few programmers in the Perl community spend a lot of time *reading* books on software engineering and techniques thereof... and I'm not convinced about this. Although from my limited experience, I'm not very fond of them Hmmm, I'm not sure if you're talking about the programmers or the books. Ha. But seriously, I lose a lot of respect for people who don't continually study software engineering yet call themselves developers. Our craft is constantly evolving, and to ignore the material that's available to us to learn new techniques is completely irresponsible and it leads to some of the problems that we are bemoaning in this very thread. I admit I read these kinds of books fairly often, although because of the sites I do they can tend towards more general topics (Funky Business, Cluetrain Manifesto), but Extreme Programming and Rapid Development are two of the bibles. I have to say though, I've avoided the Design Patterns type books purely because of the C++/Java bias. That said, anyone who hasn't digested Damian Conway's OO Perl book is a total slacker. *snip* Dave -- 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 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
[EMAIL PROTECTED] (Randal L. Schwartz) writes: "Gunther" == Gunther Birznieks [EMAIL PROTECTED] writes: Gunther This is exactly why someone experienced in training (ie Gunther Randal/StoneHenge) would hopefully be the ones to take the Gunther torch on this. If there's anyone I would trust a Gunther certification from, it would be them. We've considered the certification route from time to time, but other than being a money maker for us (which isn't all that bad of a deal :-), I'm still not entirely convinced that the community of *ours* would demand certification in any distinguishing way. I mean, until I can demonstrate that people with certs are likely to get hired faster or make more money, what's the point? As it is now, good mod_perl people are hard enough to find that the jobseeker already has the advantage. Do it on line, for free (or real cheap)? OK so it'd be multiple-guess most of the time, but peer review of submitted coursework too? There are plenty of "intermediate" perl folk out there who only need the briefest of help in getting rocking with advanced perl and mod_perl. You're the trainer though... -- 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 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Robin Berjon [EMAIL PROTECTED] writes:
At 14:07 06/12/2000 -0500, kyle dawkins wrote:
Ok, you're missing my point but that's partially my fault for not explaining.
First, let me agree: Java's "everything is an object" mentality sucks
balls. And yes, Perl's duality of functional/OO is really nice. Taking that
away is not what I am advocating... I think there should be the *option* in
Perl to disable certain features that make Perl a dangerous language for OO
development. First and foremost, the lack of true encapsulation is
disastrous. There is no concept of private data because instance data is
stored in a blessed hash (typically) that's open wide to the world. It makes
it tough to create a true interface/implementation dichotomy that is
important in the OO world.
I've got the beginnings of an interface/implementation thing going
with Perl 5, check out ex::implements and ex::interface. They're still
not 100% there because I haven't actually written any real
documentation, and there can be problems with pre existing AUTOLOADs
for the non 'utterly strict' version, but there's the beginnings of
something decent. At least you now get an error thrown at compile time
if you haven't actually implemented everything you promised to
implement.
But until 'my Dog $spot' becomes an assertion that $spot can only be
either undefined, or something that implements the 'Dog' interface, my
code is just an experiment. Albeit a possibly useful one.
That's because of the way most people implement their classes. Perl does
have a concept of private date (although it's not built into the language
as that) and it's actually fairly easy to get that. OO Programming with
Perl by Damian Conway has plenty of example demonstrating that.
All hail Class::Contract. Slow as a dog 'cos of all the tie magic, but
*utterly* fantastic otherwise. Again, fingers crossed for Perl 6
making 'tie' or its moral equivalent nice and fast.
And there's so much in Perl that makes OO so *nice*. For instance, I
have a container class (It's a row in a shopping basket) that can be
fully specced completely independently of the stuff it contains and
yet, because of AUTOLOAD and 'can' it can present itself as if it were
the contained object to stuff that is expecting that. Which reminds
me, I really need to overload the container's 'isa' method so that it
can return true to C$container-isa('Contained').
But then another problem arises: Because C{}-isa(...) throws an
exception, too much code ends up doing CUNIVERSAL::isa($foo, 'Bar').
Good, friendly polymorphic behaviour would have
C$unblessed_ref-isa(...) and C$unblessed_ref-can(...) returning
sensible values. Some sort of $random_ref-is_blessed() method might
be handy too.
And here we are, too late for a perl6.language rfc...
--
Piers
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Wed, Dec 06, 2000 at 01:22:26PM -0800, Randal L. Schwartz wrote: "Gunther" == Gunther Birznieks [EMAIL PROTECTED] writes: Gunther This is exactly why someone experienced in training (ie Gunther Randal/StoneHenge) would hopefully be the ones to take the Gunther torch on this. If there's anyone I would trust a Gunther certification from, it would be them. We've considered the certification route from time to time, but other than being a money maker for us (which isn't all that bad of a deal :-), I'm still not entirely convinced that the community of *ours* would demand certification in any distinguishing way. I mean, until I can demonstrate that people with certs are likely to get hired faster or make more money, what's the point? As it is now, good mod_perl people are hard enough to find that the jobseeker already has the advantage. I'm very open to being convinced otherwise though. I'd be interested in something like this. For a low price ($50-$100), I'd take a list of activities from your website, complete the activities, submit my code back to you, and let you grade me, and then send me some form of certificate saying "Certified mod_perl hacker" with Stonehenge and the famous merlyn signing it. If we could get Doug and Lincoln to sign off on the list of activities, the certification couldn't get more genuine than that. Having one of the great perl hackers, the creator of mod_perl, and a few other luminaries endorse the program would be a boon. By the way, does mod_perl have a "board of directors"? If there was a mod_perl consortium backing mod_perl (Merlyn, Lincoln, Doug, Stas etc) formally, I'm sure we could get some pretty serious notice. How many technologies have the actual creator as part of the certification process? It could only help. Even if someone open books the exercises, the certification would still be valid. How many times are you forced to write something without reference of any kind? Just my $0.02. If I forgot to add kudos to any one individual, I apologize. I don't mean to leave anyone out. JJ -- J. J. Horner [EMAIL PROTECTED] "The people who vote decide nothing. The people who count the vote decide everything." - Josef Stalin "The tree of liberty must be watered periodically with the blood of tyrants and patriots alike. ... Resistance to tyrants is obedience to God." - Thomas Jefferson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
At 07:12 AM 12/7/00 -0500, barries wrote: On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: the only thing I would add is DBI and DBD:::CSV, No joins. Therefore not very useful. Actually joins are over-rated for most simple apps. It's very easy to make a calendar, address book and other common apps w/o joins. With that said though, DBD::CSV has some serious short-comings. Not the least of which is the lack of file locking. But because of the popularity of flatfile databases for newbies, that's why in our application toolkit we ended up making an abstraction that sits about more than just DBI -- native flatfiles, XML files, LDAP, SOAP, etc.. called DataSource with its own query language roughly similar in concept to Microsoft's ADO. Love it or hate it (most people who have used it do love it or hate it). you get a basic prototyping db and you can add other drivers as you need them. And the package needs to specify the version of gcc it was built with, so you can add dso's and/or perl XS modules. If you're doing that, you've graduated yourself to recompiling the whole kit and kabootle. That's probably true. One thing that would make things much easier for mod_perl is to get the DSO mechanism fully working. A lot of ISPs compile apache with DSO support, and so making mod_perl work well with DSO would help so that you don't have to ship a pre-compiled apache. Anyway, I think people need binary distributions really. Make is too complicated for a lot of newbies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
Installing: I've installed mod_perl twice in the last month. The first time was on Solaris and was quite painless. The second time was on RH 7.0, and was fairly painful. Took most of a day of futzing around to finally get it installed and working. I ran into two problems, first the unrecognized version of apache 1.3.14, and second when I had downgraded to 1.3.12 the new auto-configure part of apache was bypassing the standard Configuration file which mod_perl had inserted itself into, so Apache was building itself without mod_perl. As several others have said here, there is work which could be done in this area. My suggestions would be: - easier install in general (big red button approach is always nice) - make it easier (clear instructions too) on how to configure apache with mod_perl and other modules. The current 'big red button' only works if you have no other modules or already have them configured. - Instructions written for someone who knows nothing about mod_perl, and possible very little about unix. This is a general problem for all open source What's so complicated about this: % cd /usr/src % lwp-download http://www.apache.org/dist/apache_x.x.x.tar.gz % lwp-download http://perl.apache.org/dist/mod_perl-x.xx.tar.gz % tar xzvf apache_x.x.x.tar.gz % tar xzvf mod_perl-x.xx.tar.gz % cd mod_perl-x.xx % perl Makefile.PL APACHE_SRC=../apache_x.x.x/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 % make make test make install % cd ../apache_x.x.x % make install and slurping into httpd.conf: PerlModule Apache::Registry Alias /perl/ /home/httpd/perl/ Location /perl SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI /Location and running: % apachect start to get started with... works out of box on most Unix flavors. Your problem is that you try to use the precompiled broken packages provided by distros. Try this command :) perl -le \ 'print "Build from source! Do NOT use mod_perl binary rpms!" while 1' _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
at a time earlier than now, kevin montuori wrote: Aaron E Ross writes: aer the possibility of being able to untar one package to get aer mod_perl w/ persistent db connections, [c.] is very glamorous! agreed. but fundamentally impossible. what database are you going to provide persistent connections to? mysql? not on my solaris box you're not, unless you're going to include mysql in your distribution. besides, i want sybase. ok, so skip the database and use DBM files, gdbm's everywhere, right? again, not (standard, anyway) on solaris. so, package up gdbm too. Well, I see the problem, but ... when you install J2EE or WebSphere, you don't actually get DB2 or Oracle installed too. You do however, get an interface to a connection pooling mechanism, all you have to do is code it ( and maybe configure it ). I'm imagining the same thing. If you need a feature, turn it on. No CPAN, Compilation, etc ... Rather than having to install Apache::Session,DBI,DBD each time, it should be ready to go with whatever database you are using.. or not at all. Providing compiled version of DBD drivers is harder, but not necessarily in the scope of this project. Oracle provides their own jdbc drivers, not Sun and yet it is still a easier install. I agree that providing a complete working, just add water environment is impossible, but providing the groundwork for one is not. So let's start, as you suggested, with two goals 1) bundling working versions of apache and mod_perl 2) providing summaries and descriptions of mod_perl development environments. Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
J. J. Horner writes: I'd be interested in something like this. Certification is a quagmire. If it's done well, it takes a lot of work by the certification authority, and that makes it expensive for those certified. If it's done poorly, it's useless and is just a moneymaker for the certification authority. I think that certification is only really meaningful when you have too many applicants and need to give the employers a sense of how good the applicants are. That's the Cisco and Microsoft model, even though MCSE is a joke. I don't see a surfeit of mod_perl programmers. If anything, a stark shortage. I'd rather see us find some way to churn out perl and mod_perl programmers. For instance, release a beginner class on Perl and mod_perl and have local Perlmongers lead classes. I have my slides from the University of Perl, which I'd contribute to such an effort (they're pretty closely based around the Eagle book, and some of the details should be replaced with sections on Mason et al.). Nat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
By the way, does mod_perl have a "board of directors"? If there was a mod_perl consortium backing mod_perl (Merlyn, Lincoln, Doug, Stas etc) formally, I'm sure we could get some pretty serious notice. Yes, it's called Project Management Committee (pmc) and currently the members are Doug, Eric Cholet, Ask and me. This committee is a part of the Apache Software Foundation (ASF) group, which has pmc for every project hosted under ASF umbrella. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
"Aaron E. Ross" wrote: database abstraction and connection pooling = DBI session management = Apache::Session load balancing = mod_backhand?? data relational mapping = Tangram or Alzabo templates or whatever you want to call them = HTML::Embperl/Mason/TemplateToolkit ide = pick an editor with a few hooks to call make, install and restart I'd say that load balancing is too involved an issue to make it into a package, I'd leave it aside, as anyone actually needing it will be certainly building his apaches manually. And I would also leave the IDE aside, (although I think I have a great candidate[1]). IDEs are very personal things, and users are sometimes very attached to theirs ... so much that merely installing an IDE is sometimes an offence. [1] Having grown up in a cushioned, fancy VB 3.0 IDE, I still find both vi, emacs and textmode debug too harsh for me. So I've been toying with the early releases of Komodo (http://www.ActiveState.com/Products/Komodo.html) and I actually like it although its far from finished. Has anyone used/tested it? martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Thu, Dec 07, 2000 at 03:58:48PM +0100, Stas Bekman wrote: By the way, does mod_perl have a "board of directors"? If there was a mod_perl consortium backing mod_perl (Merlyn, Lincoln, Doug, Stas etc) formally, I'm sure we could get some pretty serious notice. Yes, it's called Project Management Committee (pmc) and currently the members are Doug, Eric Cholet, Ask and me. This committee is a part of the Apache Software Foundation (ASF) group, which has pmc for every project hosted under ASF umbrella. So, if we were to look for a mod_perl certification, shouldn't this group of fine, upstanding people be the ones to design it, and have merlyn administer it through his site, or maybe this group could form a subcommittee to do the dirty work (grading, signing certificates, keeping track of certificate numbers, setting up mailing lists, etc). I truly believe that what worked for M$ could work for us. M$ proved that the key to getting any technology accepted, no matter how inferior, was to create a group of people who could advocate, administer, and sell the technology. We have a great thing here. If we could get a cert that makes people, perhaps in stages, submit handlers for all of the applicable Apache response phases, as well as create content handlers that perform database connections, add neat headers, footers, and graphics, and create theme handlers, etc, we could certify a group of dedicated, knowledgeable salesmen, programmers, hackers, etc. If I'm way off base, please let me know. I'm spending considerable brain power on this idea and if I'm wasting it, I need to know. I don't have much spare brain power and I could use it to try to figure out my wife . . . JJ -- J. J. Horner [EMAIL PROTECTED] System has been up: 3 days, 10:14. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT]Re: mod_perl advocacy project resurrection
At 14:47 06/12/2000 -0800, ed phillips wrote: Aristotle from the Ars Rhetorica on money: Money will not make you wise, but it will bring a wise man to your door. :) -- robin b. Forty two. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[certification] (was Re: RFC: mod_perl advocacy project resurrection)
On Thu, 7 Dec 2000, J. J. Horner wrote: On Thu, Dec 07, 2000 at 03:58:48PM +0100, Stas Bekman wrote: By the way, does mod_perl have a "board of directors"? If there was a mod_perl consortium backing mod_perl (Merlyn, Lincoln, Doug, Stas etc) formally, I'm sure we could get some pretty serious notice. Yes, it's called Project Management Committee (pmc) and currently the members are Doug, Eric Cholet, Ask and me. This committee is a part of the Apache Software Foundation (ASF) group, which has pmc for every project hosted under ASF umbrella. So, if we were to look for a mod_perl certification, shouldn't this group of fine, upstanding people be the ones to design it, and have merlyn administer it through his site, or maybe this group could form a subcommittee to do the dirty work (grading, signing certificates, keeping track of certificate numbers, setting up mailing lists, etc). Obviously that if this is going to happen, the teaching entity that actually gets paid for their time, will do all the work. Certainly we can "help" to define and fine tune the details at least to review things, but you understand that we cannot sign certificates, because we aren't the part of the whatever company which will do the certification. I truly believe that what worked for M$ could work for us. M$ proved that the key to getting any technology accepted, no matter how inferior, was to create a group of people who could advocate, administer, and sell the technology. It's all true, but Randal is right by saying that you need certification when you have herds of programmers and you want to have some easy (not always good) way to leverage them. The only reason I've suggested the certification idea is to do the the other way around to create the herd of mod_perl programmers, because we have a certification program. Of course I can be wrong, it's just an idea. If I'm way off base, please let me know. I'm spending considerable brain power on this idea and if I'm wasting it, I need to know. I don't have much spare brain power and I could use it to try to figure out my wife . . . :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: shared mem [was: mod_perl advocacy project resurrection]
On Wed, Dec 06, 2000 at 04:24:24PM -0800, Perrin Harkins wrote: On Wed, 6 Dec 2000, Paul wrote: I was pointed to IPC::Sharable, IPC::Sharelite. I'll look at those. Take a look at IPC::MM for a shared memory hash implemented in C. Also, File::Cache is sometimes faster than the IPC modules. I don't think any of these solve problems like sharing sockets and file handles though. Why doesn't the BerkeleyDB module get mentioned whenever this topic comes up? I think it should. Tim. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Matt, Everything required to make the module work ought to be included in the package or at least cross referenced to it. I have been having a problem in which I have had to manually resolve module dependencies on a Solaris 2.6 box. It went through several layers with several candidates for each layer. It's taken me a couple of months to get here. If you want corporate america to buy in to Perl, which seems to be the general gist of this thread, and not to loose any of the freedom you have in coding Perl, then you are going to have to find a way to make Perl easier to use. If it stays this hard, most employers are not going to let their precious IT staff devote time and energy to doing things in Perl that they can buy off the shelf elsewhere. It's really been an ugly process. My suggestion, I think that CPAN could make things a whole lot easier by simply asking the folks who wrote the module to link to the things it's dependent on. I also think that CPAN could make a good many folks lives easier by listing system requirements, when known. My point is that if things have been this bad for me, an end user (Joe Small Business Owner) would have given long ago and used php for his web site because he can probably figure that out. Matt Sergeant wrote: On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: I haven't looked at AO or AxKit, but if I can untar either one of them and just get to work, that will rule. You can't, but thats because I believe in the CPAN model - use pre-written components. I don't believe shipping all those components in AxKit (and there are a fair number required) is the right solution. Maybe I'm mistaken. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jimi Thompson Web Master L3 communications "It's the same thing we do every night, Pinky." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
At 07:56 07/12/2000 -0700, Nathan Torkington wrote: I'd rather see us find some way to churn out perl and mod_perl programmers. For instance, release a beginner class on Perl and mod_perl and have local Perlmongers lead classes. I have my slides from the University of Perl, which I'd contribute to such an effort (they're pretty closely based around the Eagle book, and some of the details should be replaced with sections on Mason et al.). That's where PerlMonth was cool. It's a pity that it disappeared. Maybe that stuff should go on take23 now. -- robin b. After all, what is your hosts' purpose in having a party? Surely not for you to enjoy yourself; if that were their sole purpose, they'd have simply sent champagne and women over to your place by taxi. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
at a time earlier than now, Stas Bekman wrote: Installing: What's so complicated about this: % cd /usr/src % lwp-download http://www.apache.org/dist/apache_x.x.x.tar.gz % lwp-download http://perl.apache.org/dist/mod_perl-x.xx.tar.gz % tar xzvf apache_x.x.x.tar.gz % tar xzvf mod_perl-x.xx.tar.gz % cd mod_perl-x.xx % perl Makefile.PL APACHE_SRC=../apache_x.x.x/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 % make make test make install % cd ../apache_x.x.x % make install nothing.. but it's even better as a shell script, set the versions and go! -=-=- start -=-=-=- #!/bin/sh #TMPDIR='/tmp' TMPDIR=$1 #APACHE_VER='1.3.14' APACHE_VER=$2 #MODPERL_VER='1.24_01' MODPERL_VER=$3 if [ $# -lt 3 ]; then echo "Usage: mod_perl.sh tmpdir modperl version # apache version #"; exit; fi cd $TMPDIR lwp-download "http://www.apache.org/dist/apache_$APACHE_VER.tar.gz" lwp-download "http://perl.apache.org/dist/mod_perl-$MODPERL_VER.tar.gz" tar vzxf apache_$APACHE_VER.tar.gz tar vzxf mod_perl-$MODPERL_VER.tar.gz cd mod_perl-$MODPERL_VER # Add this arg to APACI_ARGS if you are on RedHat # --with-layout=RedHat perl Makefile.PL APACHE_SRC=../apache_$APACHE_VER/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACI_ARGS='--enable-shared=max --disable-shared=perl --enable-module=most' make make test make install cd ../apache_$APACHE_VER make install echo "* Done! **" -=-=- end -=-=-=-=- Anyone have code to handle the config file? Aaron and slurping into httpd.conf: PerlModule Apache::Registry Alias /perl/ /home/httpd/perl/ Location /perl SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI /Location and running: % apachect start to get started with... works out of box on most Unix flavors. Your problem is that you try to use the precompiled broken packages provided by distros. Try this command :) perl -le \ 'print "Build from source! Do NOT use mod_perl binary rpms!" while 1' _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Thu, 7 Dec 2000, Jimi Thompson wrote: Matt, Everything required to make the module work ought to be included in the package or at least cross referenced to it. I have been having a problem in which I have had to manually resolve module dependencies on a Solaris 2.6 box. It went through several layers with several candidates for each layer. It's taken me a couple of months to get here. If you want corporate america to buy in to Perl, which seems to be the general gist of this thread, and not to loose any of the freedom you have in coding Perl, then you are going to have to find a way to make Perl easier to use. If it stays this hard, most employers are not going to let their precious IT staff devote time and energy to doing things in Perl that they can buy off the shelf elsewhere. It's really been an ugly process. My suggestion, I think that CPAN could make things a whole lot easier by simply asking the folks who wrote the module to link to the things it's dependent on. I also think that CPAN could make a good many folks lives easier by listing system requirements, when known. My point is that if things have been this bad for me, an end user (Joe Small Business Owner) would have given long ago and used php for his web site because he can probably figure that out. I'm starting to come around to this now, especially with AxKit which relies on so many modules. I used to be a big fan of Activestate's PPM system (still am, only I don't use NT any more). I just wish it could work reliably on Linux, with so many different linux versions around. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
"Bruce W. Hoylman" wrote: "Matthew" == Matthew Kennedy [EMAIL PROTECTED] writes: snip Matthew compiled enterprise app might only be 300Kb (and not just a Matthew "report queue manager"). And 500Mb of memory? That's Matthew tuppence in the server world anyway. This happens to be minimum numbers for working with a particular Application Server marketed by a well-known database vendor by the name of Oracle Corp. ;-) Could someone actually be using Oracle's Application Server! Matthew I think it's exciting to think what an n-tier framework in Matthew Perl might look like. IMHO, it should be more than just the Matthew outgrowth of CPAN's contents. I agree, but I should be able to expand and contract this middle tier monster in a very similiar fashion. Hey, I want some functionality, get it, configure it, install use it, derive from it, whatever. On the other hand, if I don't want, I can wipe it out without horking up the entire system. I agree with this. A pluggable architecture is nice. Incidentally, that's what the J2EE platform offers as well. For instance; I don't have to use JavaMail with EJB, or the Java Messaging System with EJB, or even JDBC with EJB either etc. Those modules would not necessarily have to be loaded into a JVM in order for me to use the rest of the framework. Sounds to me that this would not be too hard to do in a Perl context either. I think in general the work gone into J2EE's specification and rationale might be an excellent requirements model for a Perl n-tier equivalent. snip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Thu, 7 Dec 2000, Nathan Torkington wrote: J. J. Horner writes: I'd be interested in something like this. Certification is a quagmire. If it's done well, it takes a lot of work by the certification authority, and that makes it expensive for those certified. If it's done poorly, it's useless and is just a moneymaker for the certification authority. I think that certification is only really meaningful when you have too many applicants and need to give the employers a sense of how good the applicants are. That's the Cisco and Microsoft model, even though MCSE is a joke. I don't see a surfeit of mod_perl programmers. If anything, a stark shortage. I'd rather see us find some way to churn out perl and mod_perl Isn't the word 'churn' copyrighted by Guy Kawasaki? :) programmers. For instance, release a beginner class on Perl and mod_perl and have local Perlmongers lead classes. I have my slides from the University of Perl, which I'd contribute to such an effort (they're pretty closely based around the Eagle book, and some of the details should be replaced with sections on Mason et al.). Yup, I agree with Nat, if everyone will contribute a little to convince others that mod_perl rules, we will solve a big part of the problem. You can use my slides/handouts as well: http://stason.org/talks/. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Thu, Dec 07, 2000 at 07:56:09AM -0700, Nathan Torkington wrote: J. J. Horner writes: I'd be interested in something like this. Certification is a quagmire. If it's done well, it takes a lot of work by the certification authority, and that makes it expensive for those certified. If it's done poorly, it's useless and is just a moneymaker for the certification authority. I see your point. I was just thinking that creating a program would give some public credibility to the mod_perl community, which would then allow an entrance point into the community, which would increase numbers, which would increase message coverage, which would increase usage, which would increase word-of-mouth, which would give credibility, etc, etc. I think that certification is only really meaningful when you have too many applicants and need to give the employers a sense of how good the applicants are. That's the Cisco and Microsoft model, even though MCSE is a joke. I don't see a surfeit of mod_perl programmers. If anything, a stark shortage. I could see a use for certification for when we have too few. If we convert the few uncertified to certified, then get the acronym (CMPP??) known, this could be a way to identify the mod_perl community and provide press coverage. I'd rather see us find some way to churn out perl and mod_perl programmers. For instance, release a beginner class on Perl and mod_perl and have local Perlmongers lead classes. I have my slides from the University of Perl, which I'd contribute to such an effort (they're pretty closely based around the Eagle book, and some of the details should be replaced with sections on Mason et al.). The mod_perl book is a very valued reference book for me. I rarely leave home without it, so to speak. I do see your point, and you are probably right. I feel we are in a chicken-egg situation here: we need people, so we need coverage and media, so we can get people. I hate seeing very worthy technologies die in favor of less worthy, yet more hyped technologies. We need to beat them at their own game, it seems. Thanks, JJ -- J. J. Horner [EMAIL PROTECTED] System has been up: 3 days, 10:14. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Thu, Dec 07, 2000 at 07:56:09AM -0700, Nathan Torkington wrote: J. J. Horner writes: I'd be interested in something like this. Certification is a quagmire. If it's done well, it takes a lot of work by the certification authority, and that makes it expensive for those certified. If it's done poorly, it's useless and is just a moneymaker for the certification authority. Agreed. I think that certification is only really meaningful when you have too many applicants and need to give the employers a sense of how good the applicants are. I'd add that certifaction is perceived as being a hallmark of a "serious technology" by PHBs that don't know better. From our point of view, that makes certification a viable "marketing" tool: look this technology is sophisticated and advanced enough that there's a certification program for it. But the lack of demand for well done/costly certification amongst mod_perl programmers kills it right now. The crying deficit of us means that none of us needs to pay for certification to get the next job. I'd probably do it so I could maybe charge more and to find and help fill out areas in my knowledge that I've missed the classes in the scholl of hard knocks, but then again, maybe not. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Thu, Dec 07, 2000 at 03:52:01PM +0100, Stas Bekman wrote: What's so complicated about this: When everything goes right, and when you happen to have lwp installed and a tar that uncompresses :-). Seems like a good process to encode in a build_my_mod_perl.pl, FWIW. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Thu, 7 Dec 2000, Robin Berjon wrote: At 07:56 07/12/2000 -0700, Nathan Torkington wrote: I'd rather see us find some way to churn out perl and mod_perl programmers. For instance, release a beginner class on Perl and mod_perl and have local Perlmongers lead classes. I have my slides from the University of Perl, which I'd contribute to such an effort (they're pretty closely based around the Eagle book, and some of the details should be replaced with sections on Mason et al.). That's where PerlMonth was cool. It's a pity that it disappeared. Maybe that stuff should go on take23 now. I'd love that. In fact anything that anyone had waiting to go onto PerlMonth please drop a mail to [EMAIL PROTECTED] and we'll get you published. (assuming that PerlMonth isn't going to resurrect itself) NB: Don't mail me direct - take23 is a group effort. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Thu, Dec 07, 2000 at 03:52:01PM +0100, Stas Bekman took time to write: Your problem is that you try to use the precompiled broken packages provided by distros. If I can jump... I must say that I *never* had a problem with Debian packages of mod_perl. Maybe RedHat packages have (don't known I don't use that), but Debian packages are correct for me. So on a Debian System, you just need to do : apt-get install libapache-mod-perl and tweak the configuration files. At least that's my experience. (BTW, kudos the the Debian maintainer which probably reads this list) Regards, -- Patrick. ``C'est un monde qui n'a pas les moyens de ne plus avoir mal.'' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
On 7 Dec 2000, David Hodgkinson wrote: Development are two of the bibles. I have to say though, I've avoided the Design Patterns type books purely because of the C++/Java bias. you sure are missing out. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
I don't know about that, getting the correct version of perl, mod_perl. apache and all the preconfigured modules together and configuring cpan... as apposed to installing DBD::Postgres(uses XS), hell I could stick gcc postgres and open ldap in the package. krap I just gave my self more work. Here is the list so far: apache postgres openldap perl mod_perl libnet configure CPAN DBI DBD::CSV DBD:Pg BerkleyDB 3.x (openLDAP), this could cause a problem 2.x in in some linuxs glibc, I think berkelyDB perl module GCC gmake This gives you a nice base system and everything you need to add stuff to it. Now I have 2 questions for the list: 1: is this a good idea or a waste of my time 2: did I forget anything marc - Original Message - From: barries [EMAIL PROTECTED] To: Marc Spitzer [EMAIL PROTECTED] Cc: mod_perl list [EMAIL PROTECTED]; Marc Spitzer [EMAIL PROTECTED] Sent: Thursday, 7. December 2000 7:12 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: the only thing I would add is DBI and DBD:::CSV, No joins. Therefore not very useful. you get a basic prototyping db and you can add other drivers as you need them. And the package needs to specify the version of gcc it was built with, so you can add dso's and/or perl XS modules. If you're doing that, you've graduated yourself to recompiling the whole kit and kabootle. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On 7 Dec 2000, David Hodgkinson wrote: [...] Do it on line, for free (or real cheap)? OK so it'd be multiple-guess most of the time, but peer review of submitted coursework too? Then I like mjd's "certification" much much better. Certification done right doesn't matter. Certification not done right is harmful. - ask -- ask bjoern hansen - http://ask.netcetera.dk/ more than 70M impressions per day, http://valueclick.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Marc, In order to be kind to newbie's, you will need to mention tar and gnu zip which don't come standard on some flavors of Unix. In my case Solaris 2.6 only has tar. Zip must be installed. Also, you are going to need to at least point them to documentation. Maybe we could make extra $$$ selling tech support for your bundle (a la Red Hat)??? The extra cabbage could go to buying ads. I think the goal of the "total installation" should be something akin to M$ Office if you are aiming at the corporate/business user. PHB's like things that they feel like they can control. I have no idea how you could idiot proof this, though, unless you set LOTS of defaults. Marc Spitzer wrote: I don't know about that, getting the correct version of perl, mod_perl. apache and all the preconfigured modules together and configuring cpan... as apposed to installing DBD::Postgres(uses XS), hell I could stick gcc postgres and open ldap in the package. krap I just gave my self more work. Here is the list so far: apache postgres openldap perl mod_perl libnet configure CPAN DBI DBD::CSV DBD:Pg BerkleyDB 3.x (openLDAP), this could cause a problem 2.x in in some linuxs glibc, I think berkelyDB perl module GCC gmake This gives you a nice base system and everything you need to add stuff to it. Now I have 2 questions for the list: 1: is this a good idea or a waste of my time 2: did I forget anything marc - Original Message - From: barries [EMAIL PROTECTED] To: Marc Spitzer [EMAIL PROTECTED] Cc: mod_perl list [EMAIL PROTECTED]; Marc Spitzer [EMAIL PROTECTED] Sent: Thursday, 7. December 2000 7:12 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: the only thing I would add is DBI and DBD:::CSV, No joins. Therefore not very useful. you get a basic prototyping db and you can add other drivers as you need them. And the package needs to specify the version of gcc it was built with, so you can add dso's and/or perl XS modules. If you're doing that, you've graduated yourself to recompiling the whole kit and kabootle. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jimi Thompson Web Master L3 communications "It's the same thing we do every night, Pinky." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
On Thu, 07 Dec 2000 11:33, you wrote: On 7 Dec 2000, David Hodgkinson wrote: Development are two of the bibles. I have to say though, I've avoided the Design Patterns type books purely because of the C++/Java bias. you sure are missing out. I second that. You should lose your anti-engineering bias just because of your anti-Java/C++ bias. Design patterns have nothing whatsoever to do with Java and C++, and if you ignore them, you ignore solutions to problems that plague every developer. Design patterns are fundamental to everything we do, even if we don't know it. That's not to say that they will somehow solve all your problems, but a responsible developer should learn about as many problem-solving techniques as possible. Ok, I'll get off my soapbox now. :-) Kyle -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Thanks for pointing that out, or I could just use compress. As far as the $$$ goes you need to spend money to start a business lets see if there is a market first. Another thing we could add is interbase to the list or break it up into 3 or more packages that are integrated out of the box, call it rev 2( with no rev 1 yet). here is what I see if I do that later: 1: apache/perl/modperl/dbi/dbd for all supported db and there client code/ldap client 2: open ldap/berkelydb 3: postgress 4: interbase 5: mysql ... more stuff here N: auxiliary package gcc/gmake and what ever else these components would all have to work out of the box with each other, I install 1 on my web server and 2 on my ldap box and it works or I install both on 1 box and it works. Everything should go under 1 directory /opt/something/(apache|ldap|postgress) etc. This will be a good deal of not fun work though. The way to idiot proof something is to not listen to idiots, this is where it goes and that is the end of it. Give people a list of where each default is web root, datafiles for interbase postgres openldap in a step by step pre install guide and have them start at step 1 and go to step N and you have installed the package(s) you need. marc - Original Message - From: Jimi Thompson [EMAIL PROTECTED] To: Marc Spitzer [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, 7. December 2000 13:40 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) Marc, In order to be kind to newbie's, you will need to mention tar and gnu zip which don't come standard on some flavors of Unix. In my case Solaris 2.6 only has tar. Zip must be installed. Also, you are going to need to at least point them to documentation. Maybe we could make extra $$$ selling tech support for your bundle (a la Red Hat)??? The extra cabbage could go to buying ads. I think the goal of the "total installation" should be something akin to M$ Office if you are aiming at the corporate/business user. PHB's like things that they feel like they can control. I have no idea how you could idiot proof this, though, unless you set LOTS of defaults. Marc Spitzer wrote: I don't know about that, getting the correct version of perl, mod_perl. apache and all the preconfigured modules together and configuring cpan... as apposed to installing DBD::Postgres(uses XS), hell I could stick gcc postgres and open ldap in the package. krap I just gave my self more work. Here is the list so far: apache postgres openldap perl mod_perl libnet configure CPAN DBI DBD::CSV DBD:Pg BerkleyDB 3.x (openLDAP), this could cause a problem 2.x in in some linuxs glibc, I think berkelyDB perl module GCC gmake This gives you a nice base system and everything you need to add stuff to it. Now I have 2 questions for the list: 1: is this a good idea or a waste of my time 2: did I forget anything marc - Original Message - From: barries [EMAIL PROTECTED] To: Marc Spitzer [EMAIL PROTECTED] Cc: mod_perl list [EMAIL PROTECTED]; Marc Spitzer [EMAIL PROTECTED] Sent: Thursday, 7. December 2000 7:12 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: the only thing I would add is DBI and DBD:::CSV, No joins. Therefore not very useful. you get a basic prototyping db and you can add other drivers as you need them. And the package needs to specify the version of gcc it was built with, so you can add dso's and/or perl XS modules. If you're doing that, you've graduated yourself to recompiling the whole kit and kabootle. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jimi Thompson Web Master L3 communications "It's the same thing we do every night, Pinky." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Thu, 7 Dec 2000, Matt Sergeant wrote: On Thu, 7 Dec 2000, Robin Berjon wrote: At 07:56 07/12/2000 -0700, Nathan Torkington wrote: I'd rather see us find some way to churn out perl and mod_perl programmers. For instance, release a beginner class on Perl and mod_perl and have local Perlmongers lead classes. I have my slides from the University of Perl, which I'd contribute to such an effort (they're pretty closely based around the Eagle book, and some of the details should be replaced with sections on Mason et al.). That's where PerlMonth was cool. It's a pity that it disappeared. Maybe that stuff should go on take23 now. I'd love that. In fact anything that anyone had waiting to go onto PerlMonth please drop a mail to [EMAIL PROTECTED] and we'll get you published. (assuming that PerlMonth isn't going to resurrect itself) Actually its kinda has been resurrected. Or it will be on the upcoming monday. There are a lot of mod_perl articles on PelrMonth and it will continue. Next issue has an article by Stas and Gerald Richter. As far as articles are concerned perlmonth.com has about 20 or so mod_perl related articles. I know I've kinda been absent for some time. And I want to publicly apologize to the readers and the writers. But the next issue will be out upcoming monday. I am also contemplating on starting www.apachemonth.com, and looking for someone to possibly write mod_perl related articles on such topics like, handling different phases of Apache with mod_perl, writing PerlTransHandlers, explanations on *Handlers, stuff that is more closely related to Apache, rather than templating solutions and such, which serve better under PerlMonth. If anyone is interested in that please drop me a line or two. - Baiju Thakkar http://www.perlmonth.comhttp://www.linuxmonth.com Just use Perl; #!/boot/linux - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
This has been a really interesting thread. I would like to contribute my own experiences as I am currently sitting on both sides of the fence. In my spare time, what little there is, I operate a web hosting service for NZ Christian churches, organisations and ministries. This endeavour also operates as a ministry and hence comes under some very real constraints, the biggest being a very low budget. I can not afford to run top-end servers so must make the best of fairly modest equipment. I can not afford to hire programmers, so I do all the system admin and programming myself. I opted for Perl as I was reasonably comfortable with it and wanted an environment where I could build what I needed quickly and it would be relatively easy to look after. In the early days, I used to pull my hair out trying to get each new release of apache and mod_perl running, the problem was usually compounded by adding SSL. The arrival of Ralph's mod_ssl and the more recent apache and mod_perl distributions have helped heaps. What do I do with mod_perl, at this time it serves 3 purposes 1. It allows me to use my PostgreSQL database for web authentication (AuthDBI), 2. It offers database connection persistence, 3. It operates as a CGI accelerator. I haven't needed to work directly with mod_perl but have some things I would like to use it for next year. But my own site is only one of 150 odd on the server and I am the only one using mod_perl, a couple of sites use PHP, why ? The simple answer is - I can. It is my environment and I have control over the whole shooting match, I can fiddle the apache config as necessary, I can easily add perl .pm's as needed. I am technically competent and used to working with non-trivial technologies. I work in the IT department of one of NZ's Universities, I have been here for years and consequently have watched and been involved with technologies that have come and gone. The latest area that our applications people are working with is using the web to deliver information from and interacting with our student management system, a large Ingres Database. The current application is run as a CGI and is written as a monolithic perl programme. Simply put, it is a disaster. The people who wrote it, learned perl as they went, and being fair to them, it works. Their architecture enabled them to add functions reasonably quickly, but the application does not scale. They are not using any database connection persistence at all and multiple concurrent session very quickly kill the web server, a high-end Compaq alpha. This application has seen us through the last 12 months but is hopefully to be replaced. With what ? Well, it would seem that no amount of arguing by the systems programmers or myself is going to be successful in getting them to continue with perl, but in a mod_perl environment. They are going to go the Java way, the reasons have all been stated in this thread before; Market hype, its an expensive solution so it must be good, its a cool new technology, you can't get good perl programmers, its what is being used by everyone else, we don't understand mod_perl ( they don't understand the java solution either ), we can buy the business logic we don't have to build it ... I like the perl/mod_perl solution, it works well for me, I believe it is also an appropriate technology for solving enterprise problems. The biggest hurdle we have faced in trying to get it considered has been market perception. If we had been able to find recognised or well-known enterprise/corporate/large site implementations to use as reference sites, it might have helped. To be able to say that site X uses a mod-perl solution and they are using Ingres/Oracle/Sybase or whatever and getting umpteen thousand hits a day gives the technology creditability. The Microsoft and Java marketing machines have given their technologies credibility (whether they deserve it or not is irrelevant). The decision has been made, unfortunately, so much of this is now water under the bridge but a list of reference sites might help others construct better cases for their management. -- Glen Eustace, Systems Engineer - Networking. Information Technology Services, Turitea, Massey University, Palmerston North, NZ. Ph: +64 6 350 5799 x 2707, Fax: +64 6 350 5607 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Thu, 7 Dec 2000, Jimi Thompson wrote: Everything required to make the module work ought to be included in the package or at least cross referenced to it. Newer versions of CPAN resolve dependencies for you, and you can always make a Bundle:: for your project. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Alliance? WAS - Re: RFC: mod_perl advocacy project resurrection
What about working with ActiveState? I know they were primarily Windows focused, but they now have Linux and Solaris versions of Perl pre compiled. mod_perl can now be gotten to work with the latest ActivePerl build (622) for Windows. (thanks to Randy Kobes, or at least I think that is who has pushed for this) I have to admit that until their compile worked with mod_perl I saw them as 'evil' through the eyes of Perl. ActiveState (c|w)ould give credibility to the mod_perl from a business standpoint. ActiveState also has the new Komodo IDE which is a cross platform IDE for Perl and Python. It uses the Mozilla engine. http://www.activestate.com/Corporate/Communications/Releases/Press974947521.html (for the seperate discussion of GUI interfaces) Should someone try to form an alliance with ActiveState to insure they don't ignore mod_perl users or want to be users? Aaron Johnson Stas Bekman wrote: Well as you've probably figured out, based on the load of email from me, I've dropped my last job, in order to finally finish the mod_perl book, have some rest and make a push to mod_perl. Yesterday I've updated the stats page: http://perl.apache.org/netcraft/ and the results are so-so, we go down on the number of domains. Which I suppose mainly caused by people reading the guide and deploying the front-end proxy solution, thus making mod_perl un-seen by various scanners like netcraft. In Paris we couldn't hire a single mod_perl programmer, because people don't even know what that. They know a lot about php and ASP. It's true that they don't even know what's Perl :( But, you all know that php pretty much takes over. Why? For two reasons: 1) initial corporate pushing (press/ads) 2) once well known, the word of the mouth does the rest. mod_perl lucks the corporate money/PR to get pushed. But we can still work on the exposure, which will bring corporate money/PR thru the word of the mouth. Luckily Matt has got sick of waiting for someone to work on the advocacy of mod_perl and he has just taken over it. Having a good informational site is good, but it's not enough. We need to solve the problem of people to find this site and wanting to use mod_perl. Solution? Spreading the word. I see two main streams: 1) Online zines. 2) Conferences. I think that we should start working on locating ezines wanting to publish mod_perl related articles (preferrably for a fee, to give incentives for others to write) and conferences where mod_perl can be relevant. The data is to be collected and distributed to the people who wish to advocate mod_perl, thru written articles and conference classes. I suppose that we will also look for companies who want to order mod_perl classes and find the teachers in the appropriate areas. May be we could organize some certification classes, to give more PR to mod_perl. I suppose that much more can be done. Comments are welcome. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alliance? WAS - Re: RFC: mod_perl advocacy project resurrection
The could be although ActiveState has a product that competes with mod_perl on the NT side called PerlEx. What is too bad about the silence about the relationship is that PerlEx as a product could really benefit from evolving upon the back of a mod_perl code base. ...In terms of rapidly finding bugs with persistent Perl engines in a larger user base as well as sharing mod_perl's Guide (which is way better than the docs that come with PerlEx -- eg the PerlEx docs suggest sharing a DBI Handle using $dbh ||= connect() instead of Apache::DBI which would work much better under PerlEx straight out of the box!) . I've suggested this before on their PerlEx user list but have been ignored by them. Afterawhile I just stopped any suggesting as I interpret the lack of response to mean that they feel differently but for whatever reason won't state such reasons publicly and don't feel its worth the time in lieu of anything else. Maybe they would feel different now if someone else approached them. At 05:07 PM 12/7/00 -0500, Aaron Johnson wrote: What about working with ActiveState? I know they were primarily Windows focused, but they now have Linux and Solaris versions of Perl pre compiled. mod_perl can now be gotten to work with the latest ActivePerl build (622) for Windows. (thanks to Randy Kobes, or at least I think that is who has pushed for this) I have to admit that until their compile worked with mod_perl I saw them as 'evil' through the eyes of Perl. ActiveState (c|w)ould give credibility to the mod_perl from a business standpoint. ActiveState also has the new Komodo IDE which is a cross platform IDE for Perl and Python. It uses the Mozilla engine. http://www.activestate.com/Corporate/Communications/Releases/Press974947521.html (for the seperate discussion of GUI interfaces) Should someone try to form an alliance with ActiveState to insure they don't ignore mod_perl users or want to be users? Aaron Johnson Stas Bekman wrote: Well as you've probably figured out, based on the load of email from me, I've dropped my last job, in order to finally finish the mod_perl book, have some rest and make a push to mod_perl. Yesterday I've updated the stats page: http://perl.apache.org/netcraft/ and the results are so-so, we go down on the number of domains. Which I suppose mainly caused by people reading the guide and deploying the front-end proxy solution, thus making mod_perl un-seen by various scanners like netcraft. In Paris we couldn't hire a single mod_perl programmer, because people don't even know what that. They know a lot about php and ASP. It's true that they don't even know what's Perl :( But, you all know that php pretty much takes over. Why? For two reasons: 1) initial corporate pushing (press/ads) 2) once well known, the word of the mouth does the rest. mod_perl lucks the corporate money/PR to get pushed. But we can still work on the exposure, which will bring corporate money/PR thru the word of the mouth. Luckily Matt has got sick of waiting for someone to work on the advocacy of mod_perl and he has just taken over it. Having a good informational site is good, but it's not enough. We need to solve the problem of people to find this site and wanting to use mod_perl. Solution? Spreading the word. I see two main streams: 1) Online zines. 2) Conferences. I think that we should start working on locating ezines wanting to publish mod_perl related articles (preferrably for a fee, to give incentives for others to write) and conferences where mod_perl can be relevant. The data is to be collected and distributed to the people who wish to advocate mod_perl, thru written articles and conference classes. I suppose that we will also look for companies who want to order mod_perl classes and find the teachers in the appropriate areas. May be we could organize some certification classes, to give more PR to mod_perl. I suppose that much more can be done. Comments are welcome. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
I would agree. If you want to see design patterns in practical action with relation to mod_perl.. go to http://www.extropia.com/ExtropiaObjects/ and skim through Chapters 10 (App Architecture) and on (on the individual app toolkit components). Each one contains a sidebar on how design patterns affected the design of our application toolkit for CGI and mod_perl. Later, Gunther At 08:33 AM 12/7/00 -0800, brian moseley wrote: On 7 Dec 2000, David Hodgkinson wrote: Development are two of the bibles. I have to say though, I've avoided the Design Patterns type books purely because of the C++/Java bias. you sure are missing out. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: shared mem [was: mod_perl advocacy project resurrection]
On Thu, 7 Dec 2000, Tim Bunce wrote: On Wed, Dec 06, 2000 at 04:24:24PM -0800, Perrin Harkins wrote: On Wed, 6 Dec 2000, Paul wrote: I was pointed to IPC::Sharable, IPC::Sharelite. I'll look at those. Take a look at IPC::MM for a shared memory hash implemented in C. Also, File::Cache is sometimes faster than the IPC modules. I don't think any of these solve problems like sharing sockets and file handles though. Why doesn't the BerkeleyDB module get mentioned whenever this topic comes up? I think it should. Yes, it should. I stopped bringing it up because of the problems I mentioned last time: weak documentation, tricky to install on Red Hat, and some corruption issues under heavy load. However, after switching to database-level locking it's been rock solid for us, so that seems to fix the most serious problem. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Chris Winters writes: Along with the open-source Servlet/JSP/Web Engine servers (among others): Apache Tomcat: http://jakarta.apache.org/ Jetty: http://jetty.mortbay.com/ I'm currently using the Tomcat at work, and I have to say that although I really love perl and mod_perl, there are real advantages to using java. Over the past couple of years that I've been mostly lurking on this list there have been a couple common threads: 1) Memory Usage: embedding the perl interpreter on every process uses lots of memory. This of course can be tweaked and isn't as bad on good OS's, but it is a common thread. 2) Sharing information between the processes. There's lots of different ways to do it, but none really jumps out as an end-all solution. With a system like Tomcat running in a jvm outside of apache, you only have one jvm, and you get things like being able to share a cache between all sessions alot easier. I personally find the configuration of mod_perl to be more straight forward than Tomcat, but I do see some advantages to that system (I'm sure there are some speed disadvantages to the tomcat communcation, but haven't done any benchmarks). That being said, I wonder how difficult it would be pull the perl intepreter out of mod_perl and run a perl stand-alone multi-threaded daemon which listens for mod_perl api calls... :) Things I would never even try with java: 1) Talking any client/server protocol other than URLs. The perl mail/ftp modules are so easy to use and they work great. I don't even want to think about writing to syslogd from inside java... :) 2) Spawning an external process. I try not do it in mod_perl, but I have never been able to pull it off in java. -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Jim Woodgate wrote: With a system like Tomcat running in a jvm outside of apache, you only have one jvm, and you get things like being able to share a cache between all sessions alot easier. [snip] That being said, I wonder how difficult it would be pull the perl intepreter out of mod_perl and run a perl stand-alone multi-threaded daemon which listens for mod_perl api calls... :) There is Velocigen and SpeedyCGI (or is it FastCGI?). These basically create a pool of perl interpreter daemons that respond to requests. The problem with them compared to mod_perl is that you don't have access to the server internals so you can really only affect the content handling phase. Is this the case with Tomcat as well? If so, I'd say its not really comparable to mod_perl. -dave /*== www.urth.org We await the New Sun ==*/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
At 02:18 AM 12/6/2000 -0600, Dave Rolsky wrote: On Wed, 6 Dec 2000, Jim Woodgate wrote: With a system like Tomcat running in a jvm outside of apache, you only have one jvm, and you get things like being able to share a cache between all sessions alot easier. [snip] That being said, I wonder how difficult it would be pull the perl intepreter out of mod_perl and run a perl stand-alone multi-threaded daemon which listens for mod_perl api calls... :) There is Velocigen and SpeedyCGI (or is it FastCGI?). These basically create a pool of perl interpreter daemons that respond to requests. The problem with them compared to mod_perl is that you don't have access to the server internals so you can really only affect the content handling phase. Is this the case with Tomcat as well? Yes this is the case with tomcat. If so, I'd say its not really comparable to mod_perl. It is very comparable. In the advocacy of mod_perl we are talking about losing MAJOR ground to PHP and Java from a web applications development perspective. So I think it is comparable. The fact that mod_perl can modify the internals of apache is an icing on the cake to most real-world programmers and won't make them use mod_perl or Perl at all until it becomes as easy as PHP. SpeedyCGI and TomCat are really very easy to get up and running and coding away compared to mod_perl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, (Matthew Kennedy) wrote: Transaction support for your business logic is easy in J2EE. It's not clear how you do this in Perl? Use an RDBMS. You don't understand that it can have nothing to do with a RDBMS. I'm not talking about transaction control within the context of a database within a RDBMS. As I wrote to another user on this list, say you have two database servers and you need to implement a process which operates on each database in order. Maybe you move an item from on to the other. What if the second operation fails? Natually you want to roll-back to before the operation on the first. That's what J2EE transactions are about. See how RDMBS transactions are a different deal in this situation? The problem with this analogy is that in Perl we'd just use exception handling with automatic rollback on the databases in question (assuming you don't commit). Throw an exception and be done with it. You'd probably have to come up with a better scenario where J2EE transaction management is really required. I've been struggling to grasp the need for this concept since I attended a Microsoft developer day where they demo'd their COM based transaction manager for the first time. But then I'm an old style RDBMS guy. We built multi-million dollar Sybase systems for large insurance companies. We never needed a transaction manger. shrug; -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: I haven't looked at AO or AxKit, but if I can untar either one of them and just get to work, that will rule. You can't, but thats because I believe in the CPAN model - use pre-written components. I don't believe shipping all those components in AxKit (and there are a fair number required) is the right solution. Maybe I'm mistaken. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: On Tue, 5 Dec 2000, brian moseley wrote: On Tue, 5 Dec 2000, Perrin Harkins wrote: Transaction support for your business logic is easy in J2EE. It's not clear how you do this in Perl? Use an RDBMS. what about transactions that span data sources? yes, this does happen. Yeah, it *seems* to happen, but it doesn't actually. Any vendor who tells you he can do real transactions across data sources is a liar, or using a new and improved definition of transaction. You can do it %99.99 of the time but that last %.01 is the bitch. With J2EE you get the complete illusion that you are doing txns across as many data sources on as many systems and vendors as you want, but behind the illusion there is the nonzero risk that the data is inconsistent. In a real transactional system, you can never have inconsistent data. This thread is suffering from a severe lack of technical information. Can you go into more technical detail on what that 0.01% is (and is caused by)? -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, brian moseley wrote: [coldfusion/php] how is mason not like this? It has no point-n-drool authoring tools. This is actually the killer app. Once this is done, Mason / other templating system of choice gets catapulted to the forefront MBM -- Matthew Byng-Maddick Home: [EMAIL PROTECTED] +44 20 8981 8633 (Home) http://colondot.net/ Work: [EMAIL PROTECTED] +44 7956 613942 (Mobile) Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
On Tue, 5 Dec 2000, kyle dawkins wrote: [1. two types of developer] agreed. [2. Perl4 / Perl5 ] This is also true. Although a lot of "Perl programmers" haven't got a clue about the object orientation stuff in Perl5 either. On the other side of the coin, too many people are jumping on the "It's object oriented, it must be reusable" and "The only way to solve problems is using objects" bandwagons. Java and C++ both play to these. And unfortunately they've convinced management, in general. Plus, big corporates like to deal with corporates - Java is defined by Sun, a corporate. This is always going to make our life hard... 3. Installation/setup Ok, so if you have Linux, it's a piece of cake... download all the sources, OK. but s/Linux/a UNIX or UNIX-alike/g. follow the README's, and go. But what if you don't have Linux? Or you aren't root, and what if you need access to httpd.conf to keep changing Then you don't necessarily do it on port 80. This is the only reason you need to be root. stuff? And developers are going to need to cycle the server all the time, so they need the ability to do that, too... it's definitely a weak point. I can install any one of the Java-based web application frameworks and be developing immediately. I disagree. The webserver stuff still needs to be run as root, or you run it on a different port. Although I would also suggest having a look at userv (http://www.chiark.greenend.org.uk/~ian/userv/), although there are some security holes opened up by using mod_perl. 4. Isolation A lot of mod_perl projects (or even Perl projects in general) tend to be one-person shows... maybe I'm wrong, and I'd love it if people could correct me! But in my observation, we have a lot of programmers working in isolation. This is bad. plughttp://codix.net//plug. 5. Foundation libraries Because of the open nature of the CPAN community, there are a lot of great modules floating around out there. However, there is no real API consistency in them, and this will cause newcomers to Perl a fair amount of trouble. Moreover, we're not going to get anywhere in the enterprise if people insist on using HTML templating systems that allow the embedding of code within HTML. It's straight up and down a total disaster and no right-minded software architect would ever consider it. Agreed. 6. Engineering The Perl community is made up of a truly eclectic group of people, which is an amazing strength. However, it's also an amazing weakness: I get the impression that very few programmers in the Perl community spend a lot of time *reading* books on software engineering and techniques thereof... and I'm not convinced about this. Although from my limited experience, I'm not very fond of them that lack of knowledge tends to bleed over into a lot of code out there. We have a HUGE problem in the community of the "coder superstar" mentality... yup. which is very dangerous. Perl allows far too many tricks, and often code ends up totally unmaintainable and unreadable because some coding yahoo put in some glory-code. It happens in many languages, true, but Perl is the ideal environment for it. Not necessarily. You can get coder superstars who write maintainable and understandable code. -- SO -- I hope you guys can give these points some thought. I could be "smoking grass" but I think I'm on target on most of my points and I'd love to hear what you guys think too. In the meantime, here are some ideas that might go down well (or not!): Not entirely. * We implement a "mode" under mod_perl, kind of like "use strict", that suddenly forces Perl to behave well from an object-oriented standpoint. By this, I mean taking some of the power away from Perl that causes trouble, like allowing anyone to write instance data on an arbitrary instance of a class... No. no no no. Forcing perl to behave as "Object oriented" is entirely the wrong thing. This is why Java sucks so much. "Everything is an object" (excepting, obviously, the language primitives). Perl is nice because you can write it functionally or object oriented depending on the problem you're trying to solve. Also this functionality is more core Perl than mod_perl. * We "homogenise" some foundation classes. This means we create a *suite* of classes that have consistent API, are designed together as a framework, and are easy to learn I think you need to get out of the "object-oriented-only" mentality. But yes, sort of, agreed. * We need to drop-kick DBI out of the park... it's not that it's bad (it's actually great... kudos to the DBI crew) but kind of the opposite; it's so easy to use that most people don't think beyond it. How many of you have ever thought about implementing an Object-Relational middleware layer using mod_perl? We could create a set of generic OR classes as part of our foundation framework. DBI is actually quite a hassle to use
J2EE and distributed commits (was Re: mod_perl advocacy project resurrection)
I'll bite, 'cuz I think I've run several times recently into this sort of issue. I've not done anything with J2EE, so there's a risk that I've misunderstood _that_. Now, from the top: On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: With J2EE you get the complete illusion that you are doing txns across as many data sources on as many systems and vendors as you want, but behind the illusion there is the nonzero risk that the data is inconsistent. In a real transactional system, you can never have inconsistent data. Logged relational databases have evolved to ensure "atomic"[1] transactions. This is to avoid embarrassing incidents like me giving you a dollar[2], but a system crash midway means that we both end up with the dollar. Or neither of us have it. If the application catches a SIGKILL (say), the RDBMS "rolls back" to the beginning of the transaction (I've still got my dollar). If the RDBMS catches a SIGKILL, or a digger goes through the power cable, the system is built so that it can restore itself to its previous state. A variety of safeguards are used so that transactions are very hard to lose. Often, a TX is not regarded as committed until it's been written to disk. Logs are periodically written to tape, in case the disk gets scrunched (or the RDBMS software blows up). In short: The losing of transactions is Greatly Discouraged, but can happen. _Inconsistant_ processing of transactions should be *impossible*. Distributed transactions, where you have two systems (say my bank and yours are on separate machines), simply cannot be made as reliable. There is *always* the problem that, in a single system, there is _A_ log that records whether the transaction has happened. With two systems, the record must be made in two places, and there is always an instant in time - however small - when one system can crash leaving the other believing that the transaction has been successful. (IIRC, textbooks sometimes call this the "red white army problem"). This sort of problem is *not* confined to finance. You may, for instance, be maintaining lists of usernames passwords in multiple locations. There are a variety of approaches to this sort of problem: 1. Use a single database. 2. Make one database the "slave" of the other. If the DB is too big to copy, you can use a "hybrid" approach where changes are propagated, but the DBs are periodically sync'd. Or use something like rsync, which makes two database/file trees /whatever identical without brute-force copying the whole thing. 3. Be careful with foreign keys on other people's servers ... since there may be no way to find out when those become invalid, or point to something else. (Hence, the dreaded "link rot" suffered by search engines). As evidenced by the WWW's popularity explosion, loosely coupled distributed systems are in many ways very powerful. Trying to force "everything" via a single system, whilst tackling problems of consistency transaction processing, can be crippling. Different approaches suit different apps, but pretending the problem isn't there isn't generally a good approach. Hope that helps. -- Tim Sweetman A L Digital 'Now you see this one-eyed midget shouting the word "now"...' --- Bob Dylan [1] That's unsplittable, like atoms are, except the radioactive ones, or if you're cheating and have a particle accelerator. [2] I'm guessing there are lots of Americans here, and going with the majority. When Euros are in wider use, I'll use that as my metasyntactic currency unit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
Stas Bekman wrote: Well as you've probably figured out, based on the load of email from me, I've dropped my last job, in order to finally finish the mod_perl book, have some rest and make a push to mod_perl. Well best of luck hope you have a good rest - I'll certainly buy the book! In Paris we couldn't hire a single mod_perl programmer, because people don't even know what that. They know a lot about php and ASP. It's true that they don't even know what's Perl :( I think this is a general situation - sounds similar to the uk. But, you all know that php pretty much takes over. Why? For two reasons: 1) initial corporate pushing (press/ads) 2) once well known, the word of the mouth does the rest. Well go back 2 / 2 1/2 years and PHP was little known. mod_perl lucks the corporate money/PR to get pushed. But we can still work on the exposure, which will bring corporate money/PR thru the word of the mouth. I think your on the right track, as many other popular open source things have started this way. \ Luckily Matt has got sick of waiting for someone to work on the advocacy of mod_perl and he has just taken over it. Having a good informational site is good, but it's not enough. We need to solve the problem of people to find this site and wanting to use mod_perl. Solution? Spreading the word. I see two main streams: 1) Online zines. 2) Conferences. I think that we should start working on locating ezines wanting to publish mod_perl related articles (preferrably for a fee, to give incentives for others to write) and conferences where mod_perl can be relevant. The data is to be collected and distributed to the people who wish to advocate mod_perl, thru written articles and conference classes. I suppose that we will also look for companies who want to order mod_perl classes and find the teachers in the appropriate areas. I think may people could write simple "How to ZXY" in mod_perl. PHP has excellent resources for similar things i.e how to do this or that. Very much like the Perl Cookbook. I am not saying that mod_perl does not have these, and the guide has some excellent examples, but these are often not easy to find and will not attact people half as much as reading a single all-in one atricle. May be we could organize some certification classes, to give more PR to mod_perl. Not wishing to sound negative - but certification more often causes problems - MCSE's a case in point. Overall Stas I think more aticles in the general IT press be it ezines or in paper is the way to go to raise the profile. As an aside whats happening to perl month ? as this appears to be exactly the sort of thing we need. Greg I suppose that much more can be done. Comments are welcome. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Matt Sergeant [EMAIL PROTECTED] writes: On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: I haven't looked at AO or AxKit, but if I can untar either one of them and just get to work, that will rule. You can't, but thats because I believe in the CPAN model - use pre-written components. I don't believe shipping all those components in AxKit (and there are a fair number required) is the right solution. Maybe I'm mistaken. Isn't that just a question of getting a Bundle::AxKit together? Or is that an egg-sucking thing... -- 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 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On 6 Dec 2000, David Hodgkinson wrote: Matt Sergeant [EMAIL PROTECTED] writes: On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: I haven't looked at AO or AxKit, but if I can untar either one of them and just get to work, that will rule. You can't, but thats because I believe in the CPAN model - use pre-written components. I don't believe shipping all those components in AxKit (and there are a fair number required) is the right solution. Maybe I'm mistaken. Isn't that just a question of getting a Bundle::AxKit together? Or is that an egg-sucking thing... Bundles are for when you don't have a dependency tree, which AxKit has. But the real problem is the non-perl modules. And the fact that AxKit doesn't seem to work with PHP. And the Apache-expat bug/problem. All these things make installing AxKit a bit non-trivial. I quite like the Zope model - a single distribution which just includes and installs everything you need in a single place. You get python, the httpd, the database, everything. Of course if you have more complex needs, like running Zope from within Apache, you need to do some extra work, but out of the boz Zope gives you a great system that just runs. We could do that with AxKit - just ship it with Apache, mod_perl, the whole lot. But I don't think that would appeal to Perl people somehow. Thoughts? -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Matthew Byng-Maddick wrote: On Tue, 5 Dec 2000, kyle dawkins wrote: * We implement a "mode" under mod_perl, kind of like "use strict", that suddenly forces Perl to behave well from an object-oriented standpoint. By this, I mean taking some of the power away from Perl that causes trouble, like allowing anyone to write instance data on an arbitrary instance of a class... People are looking at this sort of thing. Damian Conway wrote Tie::SecureHash and Class::Contract, which may be driving at this sort of thing. The latter implements "design by contract", as seen in Eiffel. I read Damien's paper on it, but haven't used it - there are four things that put me off: 1. The difficulty of modifying existing classes to work with it 2. The magic of "flyweight scalars", which I haven't yet got my head around 3. "This code is funky"-type disclaimers scare me. 4. It looks like he just defines "data types" as LIST, ARRAY, the usual Perl primitives. This is of limited use, IMHO; being able to _define_ rules for data types (eg. valid URI; reference to FooID in table Foo in database bar) would be more powerful. (Not that these should all be checked every time, unless you're implementing a Snail, but C::C does have the ability to switch checks off, eg, in a live environment. Though live users make very thorough testers :-/) I can see why people want encapsulation, though I've rarely seen problems due to people violating it. This may be pure luck. *Lack* of encapsulation may provide clues when you hit something with Data::Dumper find out what's going on on the inside. IMHO, assertions, data type definitions, pre post conditions are v. useful things. Define interfaces to methods functions. This isn't necessarily the right approach - especially at the beginning of a project - but it is in some cases, and AFAIK there is little to automate this stuff available in Perl. Putting up these walls can *really* help isolate problems. Eiffel Class::Contract allow conditions to be *inherited*. So these approaches work hand-in-hand with OO *and/or* re-use. Cheers -- Tim Sweetman A L Digital 'Now you see this one-eyed midget shouting the word "now"...' --- Bob Dylan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
I've dropped my last job, in order to finally finish the mod_perl book, have some rest and make a push to mod_perl. Well best of luck hope you have a good rest - I'll certainly buy the book! :) I see two main streams: 1) Online zines. 2) Conferences. I think that we should start working on locating ezines wanting to publish mod_perl related articles (preferrably for a fee, to give incentives for others to write) and conferences where mod_perl can be relevant. The data is to be collected and distributed to the people who wish to advocate mod_perl, thru written articles and conference classes. I suppose that we will also look for companies who want to order mod_perl classes and find the teachers in the appropriate areas. I think may people could write simple "How to ZXY" in mod_perl. PHP has excellent resources for similar things i.e how to do this or that. Very much like the Perl Cookbook. I am not saying that mod_perl does not have these, and the guide has some excellent examples, but these are often not easy to find and will not attact people half as much as reading a single all-in one atricle. Right, so anybody wants to get famous (well at least a little :), you wrote some cool code snippet -- describe the gist, attach the source and let others look over it. Sort of WebTechniques columns by Randal. May be we could organize some certification classes, to give more PR to mod_perl. Not wishing to sound negative - but certification more often causes problems - MCSE's a case in point. well, may be. Obviously we don't need certifications when we cannot find mod_perl programmers at all. I just thought about it as the counter-intuitive solution -- create the certification program and make people think that there are so many mod_perl programmers that we there was a need for a certification -- which will bring to the interest, since people believe that if someone is running certification program it must be good. And then once started to learn Perl/mod_perl he is actually going to realize that it's good indeed. Overall Stas I think more aticles in the general IT press be it ezines or in paper is the way to go to raise the profile. Yeah, but I don't seem to make other interested. I don't know why. Folks are too busy I guess. As an aside whats happening to perl month ? as this appears to be exactly the sort of thing we need. I don't know. Baiju told me back in August that he resumes the functionality but he has dissapeared since then. I'll try to reach him. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, Dec 06, 2000 at 12:08:59PM +, Matt Sergeant wrote: We could do that with AxKit - just ship it with Apache, mod_perl, the whole lot. But I don't think that would appeal to Perl people somehow. Thoughts? We're not (really) talking about appealing to "Perl people" here, I think, but about appealing to people who know how to spell "Perl". By this I mean we are talking about attracting developers who haven't climbed the learning curves for Perl and Apache and mod_perl and DBI and so on and would like an easy way to play with these things. If you could do a few stand-alone releases you're proposing without having to maintain too many binary releases, you would probably woo more people in to trying it. There's a big something to be said for being able to grab a "starter kit" that "just works" and play with it. Do that for RH6 7 and NT and promote the kits as nice, shallow jumping-in places and more folks will get in and paddle around a bit with AxKit, I think. If you could release a source distro of same with a big, red "make" button on it that would allow folks on FreeBSD, debian, wherever to take a stab at it too, that would be icing on the cake. Some compromises for out-of-box ease would be necessary. Make it run on a high-numbered port so any user can run it, and make it easy to reconfig to port 80 if they want to get serious. Choose a database that can be bundled and "just work". Etc. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
barries [EMAIL PROTECTED] writes: If you could release a source distro of same with a big, red "make" button on it that would allow folks on FreeBSD, debian, wherever to take a stab at it too, that would be icing on the cake. Me too ;-) I mean, what would the damage of a full-on, everything binary be? Ten, twenty megs? OK, so we argue over whether to bundle MySQL or Postgres, but I see no objection to an install that "just works". Especially if there's a whole set of application recipies bundled. -- 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 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
Stas Bekman [EMAIL PROTECTED] writes: Yeah, but I don't seem to make other interested. I don't know why. Folks are too busy I guess. It's blogger syndrome. You need to do it in parallel with the development. The only reason my mod_perl/FastCGI comparison got written was because those nice people at EMAP Online let me spend a little time in the office (and a lot more on the train!) to tidy it up. I've got a handler code fragment using the TT that needs tidying up and extending that I think would make a nice little case study. Where should we take this kind of thing? BTW, I tried subscribing to the mod_perl advocacy list: [EMAIL PROTECTED]: Sorry, no mailbox here by that name. (#5.1.1) -- 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 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
At 16:39 05/12/2000 -0800, Perrin Harkins wrote: Someone else brought this up with me off the list. Briefly, I said that this doesn't usually happen with web sites for performance reasons and that major RDBMS vendors offer things like two-phase commit. But no, there is no perl transaction service that I know of. You'd have to look at interfacing with a commercial TP monitor for that, and those are more likely to have hooks already written for Java. In which case if that's the only part of the app that requires Java (but the rest is worth doing in Perl) one could simply "use Java;". I haven't really tested it but I've heard that it works really well. -- robin b. You can tune a piano, but you can't tuna fish. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Dave Rolsky writes: The problem with them compared to mod_perl is that you don't have access to the server internals so you can really only affect the content handling phase. Is this the case with Tomcat as well? I know that you can communicate with the server in the request, it's not totally stand-alone. But I haven't looked into putting in handlers in other phases... -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
I've been following along with this thread with interest, expecially since I'm new to the mod_perl list and community (thanks for all the help so far!). I thought you might be interesed in a 'mod_perl newbie' opinion. Recently I was handed an online event calendar running under CGI and asked to get it to run under mod_perl to speed it up. I'm comfortable with perl, but by no means a guru. And this was the first time using mod_perl. In the past I've used several products which might be considered competitors to mod_perl: Web Objects and Cold Fusion. CF was horrible, I'm glad I didn't have to work with it for long. WO was very nice to work with, and it had all the ecommerce and transation logic needed to build a enterprise web application quickly. (None of my work has been in ecommerce, instead in the medical industry (patient data, lab results, etc) which has many of the same requirements). Installing: I've installed mod_perl twice in the last month. The first time was on Solaris and was quite painless. The second time was on RH 7.0, and was fairly painful. Took most of a day of futzing around to finally get it installed and working. I ran into two problems, first the unrecognized version of apache 1.3.14, and second when I had downgraded to 1.3.12 the new auto-configure part of apache was bypassing the standard Configuration file which mod_perl had inserted itself into, so Apache was building itself without mod_perl. As several others have said here, there is work which could be done in this area. My suggestions would be: - easier install in general (big red button approach is always nice) - make it easier (clear instructions too) on how to configure apache with mod_perl and other modules. The current 'big red button' only works if you have no other modules or already have them configured. - Instructions written for someone who knows nothing about mod_perl, and possible very little about unix. This is a general problem for all open source projects. With today's IT shortage, more and more sys admins are just power users who were promoted or sucked into duties because someone else left. If you want to catch their eye, make sure you talk at their level. I realize this can be a pain in you know where, and it's something that as you look to advocate you need to think about. "Do we want to target everyone, or should there be a minimum level or aptitude before we recommend someone installs this?" Anyone can walk into Staples these days and install Linux. If they have a decent distribution installing everything is easy. But even without a package manager like RH, apache is usually very painless to install. I know a number of non-profits who just have competent users maintaining a Linux server with apache, because for the most part it's trouble free. At worst they might have to restart the server. Technical Issues: The second problem I see with mod_perl is a technical one. Because of the design of mod_perl, debugging problems can be fairly involved. Is the problem my code? Or is it apache, or maybe mod_perl? Could even be perl for that matter. Take for example the problem I ran into recently. (Please don't take this as a rant just because I had problems, I'm happy with mod_perl. But I'm fairly capable around unix and compiling, instead imagine this happening to someone who wasn't that comfortable.) The event calendar works great under CGI, so I try it under mod_perl. It was written to work under mod_perl by a better perl programmer that I'll ever be (Jon Howell of Faq-o-matic fame) and is very well designed. It even worked under mod_perl with some minor changes like supplying the user/pass to the database since it wasn't running under cgiwrap any longer. And it worked! But only 90% of the time. The other 10% of the time, the client received no data, and the page generated by the script ended up in the apache log. After cleaning up one implicit database handle destruction warning the problem persisted, and I began to attempt to discover where the connection was being closed. So I did what any lazy programmer does, I added some print statements to send a note to STDERR. While these all showed up when the program worked correctly, when problem occured, the prints to STDERR dissapeared. But the html page was printed to the apache log, basicly standard error. So it looks like if the socket is closed, stderr dissapears, and stdout goes to the error log. So no pointers appeared in the log, which wasn't very helpful. Next attempt was to do some packet sniffing to see why the socket was closeing. Turns out that the web server sends an orderly release indication (T_ORDEL_IND = 132), so the client being a good citizen reponds with a orderly release request and there goes the socket. While my description of the problem was more in-depth that I meant it to be, my point is that now I'm left with the need to trace through system calls made by apache, mod_perl and my program to try and find
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
I've always considered mod_perl similar to an artist's canvas, while Java is more like a craftsman's tool kit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matt Sergeant wrote: On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: With J2EE you get the complete illusion that you are doing txns across as many data sources on as many systems and vendors as you want, but behind the illusion there is the nonzero risk that the data is inconsistent. In a real transactional system, you can never have inconsistent data. This thread is suffering from a severe lack of technical information. Can you go into more technical detail on what that 0.01% is (and is caused by)? Yup. Machine A is controlling a transaction across Machine X and Machine Y. A modifies a row in X and adds a row to Y. A commits X, which succeeds. A commits Y, which fails. Now what? A cannot guarantee a recovery on machine X because there might already be other transactions in flight on that record in that database. A cannot just try to put the record back the way it used to be, because now the commit might fail on X. The data is inconsistent. The only thing that Machine A can do now is send an email to the DBA explaining what happened and what was supposed to happen. "Fucking Hell" says the DBA, under his breath. -jwb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Gunther Birznieks wrote: Has anyone written a Perl IDE in Perl? i goofed around with a class browser/code generator a while back, but i lost interest. as i recall, #perl laughed at me when i suggested it :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matt Sergeant wrote: You can't, but thats because I believe in the CPAN model - use pre-written components. I don't believe shipping all those components in AxKit (and there are a fair number required) is the right solution. Maybe I'm mistaken. that's why Bundle::AO is nice. it's stubborn adherence to models like this, tho, that keeps us from making generational advances rather than incremental ones. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matt Sergeant wrote: I quite like the Zope model - a single distribution which just includes and installs everything you need in a single place. You get python, the httpd, the database, everything. Of course if you have more complex needs, like running Zope from within Apache, you need to do some extra work, but out of the boz Zope gives you a great system that just runs. We could do that with AxKit - just ship it with Apache, mod_perl, the whole lot. But I don't think that would appeal to Perl people somehow. Thoughts? this is how we ship our products internally at cpth. we build perl, apache, 100 or so modules, and ~150 registry scripts. then we rpm the whole thing up. the operations team just has to: rpm -i /usr/local/webmail/current/bin/wmctl start. doing something like that doesn't play nice with the os vendor distributions really, but some people might like it. another option would be to use autoconf. wrap a configure script around your entire set of components. allow it to find and use whichever ones you've already got installed. have it build and install whatever you don't already have. not very tough. also not very portable to windows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Jim Woodgate wrote: I know that you can communicate with the server in the request, it's not totally stand-alone. But I haven't looked into putting in handlers in other phases... i believe with mod_jk there is a callback model, yes. but given tomcat's valve architecture, i don't see much need to call back into apache at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, brian moseley wrote: On Wed, 6 Dec 2000, Matt Sergeant wrote: You can't, but thats because I believe in the CPAN model - use pre-written components. I don't believe shipping all those components in AxKit (and there are a fair number required) is the right solution. Maybe I'm mistaken. that's why Bundle::AO is nice. What does Bundle::AO give you that setting PREREQ_PM correctly wouldn't? it's stubborn adherence to models like this, tho, that keeps us from making generational advances rather than incremental ones. Agreed... I *do* wish that more perlers would be open to binary modules - the Activestate PPM model. While there were regularly problems with PPM, the vast majority of module installations were incredibly trivial. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matt Sergeant wrote: What does Bundle::AO give you that setting PREREQ_PM correctly wouldn't? i don't know :) i use them both. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
