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: 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: 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: 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: 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: 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: 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: 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: 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]
[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: 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: 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: 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: 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: 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]
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: 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
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: 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: 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: 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: RFC: mod_perl advocacy project resurrection
On Dec 05, Greg Cope wrote: 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. what is even funnier is that if you go back that far and look at the php mailing lists back then, you'll find the exact same conversations. :) how did php become so popular? so many hosting companies offered it as part of their hosting. fortunately for php, it targets a bit more of a niche (generating dynamic content) than mod_perl does (writing apache modules in perl) so offering it as part of a hosting package on shared servers is quite a bit easier. (of course, this only addresses scaling to a breadth of users, not scaling into the enterprise area. that just requires real marketing and hype.) jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
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. 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. OK, terminology problem... I wouldn't call them "coder superstars" *if* they write maintainable and understandable code. Perhaps I should have called them "glory coders" instead. You're totally right, there are plenty of great coders out there who conform to coding standards and don't write tricky code. But what I mean is that there is an abundance of glory-coders in the Perl community because, in a way, the community encourages it. That doesn't fly in a large-scale project and greatly reduces the chances of mod_perl being adopted in the enterprise (IMHO). * 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. 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. * 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. U, remember, this thread is about mod_perl advocacy. In my mind, we will have huge problems encouraging enterprise adoption of mod_perl without some fundamental changes. No enterprise in its right mind would choose a platform that is not OO for any large project these days. Regardless of whether you like this or not (and I can tell that you don't), it's the truth... you said it yourself. In order to fight the Java juggernaut, we have to beat them at their own game. Perl has so many advantages over Java that that shouldn't be a problem, yet it is. Primarily, it's one of perception... Perl is a scripter's language, Perl is for hackers, Perl is great for sysadmin tasks... but it's also a technical one. Java has a set of foundation classes that everyone uses. They suck festering balls, but they're there. We can learn from that and build a set of consistent classes that allow developers to build web *apps*, not a shitload of scripts that kinda work together as glorified CGI, which is what we get all too often now. Yes, Java is a sorely broken language, but it's being adopted, partially because of Sun's hype but also because it offers enterprise developers real ways to encapsulate their business logic properly. There are a few reasons why mod_perl can't fill the
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
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. 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. I also have an inheritable Class::ArrayBased somewhere on my disk that provides a framework for array based objects. Admittedly it's encapsulation through obscurity (so to say) but people that understand how it works will probably respect the encapsulation, while those that don't will fail to access the content as a hashref. -- robin b. Make it idiot proof and someone will make a better idiot. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
"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. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, Dec 05, 2000 at 09:32:41AM -0800, brian moseley wrote: On Tue, 5 Dec 2000, Stas Bekman wrote: 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. oh, there's also the part about php being so much easier to setup and to program ;) if you really feel the need to compete with php in the lowest tier web app space, you need to make simplicity your #1 goal. php is awesome entry level technology, and i almost always recommend it over perl to people who only have the desire to do casual programming for personal sites and small projects. and that's a significant percentage of the people i know doing web programming. Actually, PHP's advantage is that you can install it and all 250 sites on that machine can use it without problems. You just can't do that sanely under mod_perl. snip we need to create standards for ourselves and fully embrace them. DBI is a great example. the explosion of mod_perl presentation technologies is a great counter example. But that's merely because we don't know what we want. Its only recently that people have decided that they wish to present data in XML and use XSL to display it. Prior to then the problem has been how to separate HTML from the code in such a way that the designers have an easy to use interface to the code. Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Ben Thompson wrote: On Tue, Dec 05, 2000 at 09:32:41AM -0800, brian moseley wrote: if you really feel the need to compete with php in the lowest tier web app space, you need to make simplicity your #1 goal. php is awesome entry level technology, and i almost always recommend it over perl to people who only have the desire to do casual programming for personal sites and small projects. and that's a significant percentage of the people i know doing web programming. Actually, PHP's advantage is that you can install it and all 250 sites on that machine can use it without problems. You just can't do that sanely under mod_perl. Being in the webhosting industry, and running modperl-space.com, I'd suggest that this really is an issue... even for the hobbyist discussed earlier it's non-trivial to get a semi-serious mod-perl site online... the gap between running it off your cable modem at home and a dedicated server at a co-location facility is pretty big... our standard PHP configuration is CGI based, which gives us all the suexec benefits, and process count/size/cpu limiting by userid etc... for folks that go beyond php-cgi, we can go to mod_php, but it's rare... with mod_perl, there is no half step unless you want to call it perl-CGI ... and even then we all know the troubles of taking CGI/run-once PERL into a persistant environment... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Stas Bekman wrote: I see two main streams: 1) Online zines. 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) While I can't offer any money for articles (unless someone out there wants to sponsor the site!), hopefully if anyone has an itch to write about something they'll go along to http://modperl.sergeant.org/contribute.xml and drop us a note. However I'd also really like to see more in offline publications. For example, I've never read anything in Web Techniques, other than a Lincoln or a Merlyn article, go into detail about mod_perl, or even just review it, or review some system built on mod_perl (like Mason or Embperl for example) [*]. I have, however, seen reviews of Velocigen, which often cite mod_perl as a competitor and as difficult to install, and therefore bad (note that I do think mod_perl is still a tad too hard to install for complete newbies, but its a specious argument because you tend to only do it once or twice, and thats something not many documents focus on). [*] Actually this is a lie, I've seen an article about Mason in WT, but I'd like to see more. -- 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]
RFC: mod_perl advocacy project resurrection
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]
Re: RFC: mod_perl advocacy project resurrection
Stas Bekman writes: sb Luckily Matt has got sick of waiting for someone to work on the sb advocacy of mod_perl and he has just taken over it. Having a sb good informational site is good, but it's not enough. We need to sb solve the problem of people to find this site and wanting to use sb mod_perl. Solution? Spreading the word. i agree with what SB says, spreading the word is of primary importance. additionally, i think that some consideration should be given to how mod_perl is packaged. although it's well documented (and generally quite simple) there are three kits that need to be compiled (apache, perl, mod_perl) before the simplest handler can be tested. i think to an applications programmer who's perhaps written a few CGI scripts, setting up the infrastructure necessary to run mod_perl is a bit daunting, particularly if it also involves mod_ssl. this is the biggest complaint i've heard from new users, and i'm not certain that i have any viable solutions to offer; after all, there's gobs of documentation already, thanks to the guide. perhaps bundling the various components together and driving the configuration/build from a single script? i don't know. cheers, k. -- kevin montuori support independent booksellers -- http://www.booksense.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
At 03:49 PM 12/5/00 +0100, 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. Is this really what it is? I guess I must be ignoring the PHP ads cuz I dont see THAT many. I think #1 is a little odd because I think Perl has gotten a lot of press and advertisement compared to PHP. Mod_perl is really just a technology on top of Perl then. I think someone mentioned that the PHP website was quite rich with recipes and links to applications written to work with PHP. If people knew there was an open source source of apps for mod_perl, they'd probably be more inclined to use it because then mod_perl wouldn't be about being forced to develop an app from scratch. 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. Perhaps Covalent could sponsor an ad in a large computer magazine. I am not sure that would help necessarily though. 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 think provided Matt gets the articles, that will go a long way. I'm busy working on my submission about using CGI::Carp and mod_perl. (Just kidding about the subject matter Matt). 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. Maybe Randal's company (which I *think* specializes in training among other things) could help in that area -- the idea of mod_perl certification is more intriguing I think than just plain perl certification. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
kevin montuori wrote: additionally, i think that some consideration should be given to how mod_perl is packaged. I think it's of crucial importance the fact that a distro as widespread as RHLinux 6.x had mod_perl messed up. That has forced quite a lot of developers that were trying to get their feet wet with mod_perl to get in a complex compile sequence. That's a source of 'bad reputation', and of php developers, as the included php was old but working ;) I don't know how messed up are other distros regarding apache/mod_perl, but making sure the main distros *do* get it right is paramount to make mod_perl catch. Another item that we should really have is a good (and somehow sanctioned) RPM that replaces the apache rpm (or deb) included in broken distros. Then we can include in the guide and related pages a link for [broken-distro-name] users, so they get a suitable replacement with a similar config. That's an important issue, because a redhat user has other non-standard modules included in his rpm, such as PHP, and compiling a *complete* apache, with mod_perl, php and the kitchen sink is a daunting task -- and too high an entry price. anyway, not an easy task ... mmhhh.. martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
It'd be nice if there was an equivalent of info's "h"... i.e., an "I've got Linux, what next?" track That might seriously encourage more hobbyists =+ more open source community (is there a way to indicate that the operator should be read backwards?)
Re: RFC: mod_perl advocacy project resurrection
kevin montuori [EMAIL PROTECTED] writes: additionally, i think that some consideration should be given to how mod_perl is packaged. although it's well documented (and generally quite simple) there are three kits that need to be compiled (apache, perl, mod_perl) before the simplest handler can be tested. i think to an applications programmer who's perhaps written a few CGI scripts, setting up the infrastructure necessary to run mod_perl is a bit daunting, particularly if it also involves mod_ssl. Is the RH7.0 installation stable? It comes with everything as a DSO and _should_ work... -- 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
On Tue, Dec 05, 2000 at 11:46:38PM +0800, Gunther Birznieks wrote: Maybe Randal's company (which I *think* specializes in training among other things) could help in that area -- the idea of mod_perl certification is more intriguing I think than just plain perl certification. Now this is something I would like. I am not big on certs (I don't have a single one), but if I were to get one, this would be it. I like mod_perl, and although I have only really started writing one public mod_perl module (anyone remember Apache-AuthExpire? Didn't think so, browser differences killed it), and I've written numerous custom stuff for work (sorry can't go into detail), I'm light on content handlers. I'm more backend, since I am not the most creative knife in the box. If I could get certified with mod_perl from [merlyn] and have the certification jive with the creators, it would help me considerably when I market myself as a hired-gun mod_perl coder. And we all remember the M$ scheme of an army of papered drones chanting "Microsoft is great!". We all now that it sold M$ software more than the software really did. If we can get an elite force of mod_perl hackers on the scene to spread the gospel, we would see a big boon to mod_perl press and support. Just my unlearned $0.02. 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: RFC: mod_perl advocacy project resurrection
--- Stas Bekman [EMAIL PROTECTED] wrote: . I see two main streams: 1) Online zines. 2) Conferences. Apache.org has a whole subsection devoted to mod_perl Any idea what it would take to get a link there from webs like tpj and Perl.com? I was thinking that perl.com has a nice series of articles going for newcomers to the language, and Mark Jason-Dominus' series of red-flag articles has certainly been worth a read; wouldn't a less generic article series for less-new users interested in perl topics like Apache be worth space and a link? I've seen links to specific high-profile uses like the Human Genome Project as Perl advocacy. Wouldn't mod_perl be worth an ongoing link page in that right, perhaps with discussions of sites handling thorny problems? Or am I behind the times on that one? I'd even volunteer to write a few articles, though I hardly consider myself qualified to teach anything more than the basic concepts. I'm still on the steep side of the learning curve for designing effective and efficient subsites with handlers and some Embperl, but our shop has some odd needs that mod_perl seems built-for, and I do love to talk comments? __ 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: RFC: mod_perl advocacy project resurrection
Has anyone tried the Apache Toolbox script at www.apachetoolbox.com ? It's supposed to configure and build Apache and a large number of modules without all the manual configuration. The script is zipped to about 16k - you just downloda that and it's smart enough to fetch the tarballs for each package you've selected if they're not already there. I've only just downloaded it, and so far its pretty menu is confusing my poor terminal program, but it looks like it could ease the pain (especially the trial-and-error bit - admittedly unnecessary if you read the docs *first*! :) ) of the usual config procedures... The author also mentions plans to port it to Perl! Rufus. -Original Message- From: kevin montuori [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 05, 2000 3:51 PM To: [EMAIL PROTECTED] Subject: Re: RFC: mod_perl advocacy project resurrection Stas Bekman writes: sb Luckily Matt has got sick of waiting for someone to work on the sb advocacy of mod_perl and he has just taken over it. Having a sb good informational site is good, but it's not enough. We need to sb solve the problem of people to find this site and wanting to use sb mod_perl. Solution? Spreading the word. i agree with what SB says, spreading the word is of primary importance. additionally, i think that some consideration should be given to how mod_perl is packaged. although it's well documented (and generally quite simple) there are three kits that need to be compiled (apache, perl, mod_perl) before the simplest handler can be tested. i think to an applications programmer who's perhaps written a few CGI scripts, setting up the infrastructure necessary to run mod_perl is a bit daunting, particularly if it also involves mod_ssl. this is the biggest complaint i've heard from new users, and i'm not certain that i have any viable solutions to offer; after all, there's gobs of documentation already, thanks to the guide. perhaps bundling the various components together and driving the configuration/build from a single script? i don't know. cheers, k. -- kevin montuori support independent booksellers -- http://www.booksense.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
David Hodgkinson writes: dh Is the RH7.0 installation stable? It comes with everything as a dh DSO and _should_ work... hmmm, if i could get RH7.0 to *install* i could check that out. anaconda (read: python) can't find it's POSIX libs, so the whole thing's a bust from the get-go. (i'm a bit bitter about RH 7.) prebuilt solves the problem nicely for people running linux; however, that's not everybody. i'm sure there are sun shops out there without the sysadmin expertise to download and compile mod_perl properly. i'd rather see the configure/compile process simplified than try to provide binaries for a dozen platforms -- that would allow the folks who'd be tied to compiling each new release to do more interesting and profitable things. i'm also sure that there are "technical managers" who can be sold on Perl, since it's from a single source, but cannot be convinced that running an enterprise system on software that's been culled from three separate sources will prove robust. i know it works, you know it works, but people who'd accept a job title like "technical manager" might get nervous. personally, i have no issues with how it works now; i'm just trying to contribute what i've heard the problems are. cheers, k. -- kevin montuori support independent booksellers -- http://www.booksense.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Stas Bekman wrote: 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. oh, there's also the part about php being so much easier to setup and to program ;) if you really feel the need to compete with php in the lowest tier web app space, you need to make simplicity your #1 goal. php is awesome entry level technology, and i almost always recommend it over perl to people who only have the desire to do casual programming for personal sites and small projects. and that's a significant percentage of the people i know doing web programming. i'd love to see us evolve mod_perl with simplicity and ease of use in mind. but precisely because php exists, i think there's a more important goal for us: creating infrastructure that can get perl accepted by the pointy heads in the engineering shops and corporate it depts. competing with java, rather than php. java's got 2 things perl doesn't: a huge, well funded marketing machine, and a large set of standard apis *that were designed to work together* which have almost universal programmer acceptance. i know it's heresy, but while tmtowtdi is a cute slogan, it doesn't market us well outside the circle of perl programmers. how many of you have tried to hire engineers with significant mod_perl experience? it's almost impossible, even in san francisco which is supposed to be the wellspring of geekery. 5 out of 10 perl programmers i interview have not used mod_perl; 4 of the rest have only ever used registry; and the last guy has an equal shot at having experience with embperl, mason or his own homegrown presentation layer. there is almost no talent pool with a consistent skill set. makes it really difficult as a manager to want to continue with a mod_perl-based application when senior engineers who love java are more or less a dime a dozen. we need to create standards for ourselves and fully embrace them. DBI is a great example. the explosion of mod_perl presentation technologies is a great counter example. we need to achieve significant vendor support, in the development tools area, the enterprise software area, the content management area, etc. how many of you use rational rose for analysis design? how many of you would use it for code maintenance as well if it could round trip engineer perl? a premise of the perl philosophy is that it's fun to write code. yes, it is. but it's also fun to make money. and writing innovation applications that people pay for is much different than writing (or often re-inventing) infrastructure components. how many of you are out there trying to re-invent cisco products? i bet zero. you buy them, unwrap them and turn them on. infrastructure software should be the same way. only a few people will ever make money on threads and databases, but many many more will make money on email messages, calendar events, news articles, and item sales. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, Dec 05, 2000 at 03:54:36PM +, David Hodgkinson wrote: Is the RH7.0 installation stable? It comes with everything as a DSO and _should_ work... That's the problem: DSOs aren't stable enough, so it all too often doesn't just work :(. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
martin langhoff wrote: snip. Another item that we should really have is a good (and somehow sanctioned) RPM that replaces the apache rpm (or deb) included in broken distros. Then we can include in the guide and related pages a link for [broken-distro-name] users, so they get a suitable replacement with a similar config. That's an important issue, because a redhat user has other non-standard modules included in his rpm, such as PHP, and compiling a *complete* apache, with mod_perl, php and the kitchen sink is a daunting task -- and too high an entry price. anyway, not an easy task ... mmhhh.. martin Has anyone out there tried the apache toolbox? It looks like an interesting program that asks you what options you want in your apache, then downloads, compiles and installs your apache server. If it works as described, it would be a good option to recommend for users with broken rpms as you describe. It suposedly supports mod_perl, ssl, and even php all together somehow. I've never used it, but am planning to give it a shot next time I have to compile a new server. Its at: http://www.apachetoolbox.com/ Nathan Stitt Head Programer, Chief Cook, and Bottle Washer. Alliance Medical http://www.allmed.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
Stas Bekman writes: 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 picture only 10% of people who build web sites ever needing to use mod_perl directly. I think they're more likely to use the systems that are built *in* mod_perl, like Mason, AxKit, and so on. If there's a with a lot of information about building web sites with those systems, then you'll make people happy. I'm an editor at O'Reilly now, for those who didn't know, and I am *very* interested in a book on building websites with mod_perl technology. That's not the mod_perl book, nor the mod_perl guide, but a book on using Mason and AxKit and the other solutions to build bitching dynamic websites. Anyone interested, contact me ([EMAIL PROTECTED] or [EMAIL PROTECTED]). 1) Online zines. The O'Reilly Network is one place to push this. In January sometime there'll be a new site launched that will be perfect for this type of content. I'll let you know more closer to the date, when *I* will know more. The mod_perl advocacy site should have RSS summaries available so that updates can go into the Meerkat system (meerkat.oreillynet.com). That will also raise the image. Announce the site (I think modperl.com or perl.apache.org should be the advocacy site, which contains a pointer to the tech docs) in TPJ and via the Perl News (news.perl.org). ApacheWeek should mention it. Nat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
Paul writes: Any idea what it would take to get a link there from webs like tpj and Perl.com? Those two I can easily make happen. Send me email saying what you want a link to, and what you want the link to say. Writers for perl.com are always wanted. Pitch your article ideas to [EMAIL PROTECTED] and he'll work with you to make the good ones happen. Nat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
mod_perl is NOT PHP. It wasn't meant to be. PHP allows for embedding a scripting language inside of HTML and allows for some "neat" things. It is also I believe easier to install and setup then a related mod_perl server. Reasons/questions of new users: 1) You have to get all kinds of modules and install them just to get to a usable environment (lets face it you can't do much with a fresh install on mod_perl unless you already know mod_perl) 2) Which embedded perl code should I use if I want one? (Embperl, Apache::ASP, Mason, etc.) 3) What security module do I use? 4) How do I set up session tracking? 5) What good is session tracking? 6) How do I access a database? 7) How do I get mod_perl to work with x database? Yes some of this is in the guide, but at some point it becomes to easy just to point a user a document and assume three things: 1) The guide is written generic enough that users at any level can understand it 2) The "real" question is locatable even if the person doesn't know the "real" question 3) The guide is in a language that is familiar to them. I am all for advocating the use of mod_perl, but the basics of setup, install and usability are always going to be key. Does anyone have any figures on how long it takes to setup a mod_perl server vs. a php server? (correctly, not just running) Before we determine whether to advocate we need to term what and how to advocate. I have been using mod_perl on Windows and Linux for the last 3 years. I find it be an extremely powerful addition to a normal apache server, but the tool kit is too large and diverse for most people that are simply looking to get a little dynamic scripting done. My personal vote for how to advocate, would be better summaries of the various modules and how they can be used in real life scenarios. i.e. the thread a few months ago about have a summary of all the embedded Perl modules (Mason, Embperl, Apache::ASP etc.) outlining their strength and weaknesses in laymens terms if possible. We are also advocating the use of Perl which should be much easier since there are numerous books and example code available in print and online that will work inside of mod_perl with little or no change. I just checked out the PHP site and their online manual allows for user comments that are displayed at the end of each page. Hmm Aaron Johnson martin langhoff wrote: kevin montuori wrote: additionally, i think that some consideration should be given to how mod_perl is packaged. I think it's of crucial importance the fact that a distro as widespread as RHLinux 6.x had mod_perl messed up. That has forced quite a lot of developers that were trying to get their feet wet with mod_perl to get in a complex compile sequence. That's a source of 'bad reputation', and of php developers, as the included php was old but working ;) I don't know how messed up are other distros regarding apache/mod_perl, but making sure the main distros *do* get it right is paramount to make mod_perl catch. Another item that we should really have is a good (and somehow sanctioned) RPM that replaces the apache rpm (or deb) included in broken distros. Then we can include in the guide and related pages a link for [broken-distro-name] users, so they get a suitable replacement with a similar config. That's an important issue, because a redhat user has other non-standard modules included in his rpm, such as PHP, and compiling a *complete* apache, with mod_perl, php and the kitchen sink is a daunting task -- and too high an entry price. anyway, not an easy task ... mmhhh.. martin - 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
-Original Message- From: Ajit Deshpande [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 05, 2000 12:19 PM To: kevin montuori Cc: [EMAIL PROTECTED] Subject: Re: RFC: mod_perl advocacy project resurrection On Tue, Dec 05, 2000 at 10:51:08AM -0500, kevin montuori wrote: additionally, i think that some consideration should be given to how mod_perl is packaged. although it's well documented (and generally quite simple) there are three kits that need to be compiled (apache, perl, mod_perl) before the simplest handler can be tested. i think to an applications programmer who's [..] I think packaging is key here. For example If we can get RedHat to package the apache and mod_perl RPMs (albeit DSO) such that a basic set of handlers and modules just *work*, I think we will be whole lot better off. I think if we could all agree on a standard newbie package and get RedHat engineers to agree to it it might go a long way... I don't remember ever seeing RedHat asking this list for advice on how it should package mod_perl (Paul?) not that they could ever really get everyone on the list to agree :) but I think EVERYTHING=1 and a static build would be a majority consensus. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
additionally, i think that some consideration should be given to how mod_perl is packaged. I know that S.u.S.E. Linux (at least the german version) include a Apache with mod_perl as DSO ( but I never have tried it, I always compiled Apache/Perl/mod_perl etc. from the source), but they neither have included any of the Apache::* modules or Embperl/Mason/ASP/AxKit etc. I could try to contact them and ask if it's possible to include more of the Apache modules and maybe the guide. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Nathan Torkington wrote: I picture only 10% of people who build web sites ever needing to use mod_perl directly. I think they're more likely to use the systems that are built *in* mod_perl, like Mason, AxKit, and so on. If there's a with a lot of information about building web sites with those systems, then you'll make people happy. amen! mod_perl is for gearheads. higher layer software is for people who want to achieve a business goal, or even just make a personal site. we have a wealth of gearhead-oriented information, but almost nothing that would convince my php friends to make the switch to perl or help them migrate a site. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Aaron Johnson wrote: I am all for advocating the use of mod_perl, but the basics of setup, install and usability are always going to be key. really? how many people actually need to configure and install mod_perl itself? how many people simply need a really simple templating engine with builtin database access? aren't their needs very different? Does anyone have any figures on how long it takes to setup a mod_perl server vs. a php server? (correctly, not just running) i don't have figures, but from experience i know - once i've compiled httpd, i have almost no real configuration work to do with php. on the other hand, if i want to set up mason, i have to write 10-20 lines of perl code and access them with PerlModule or PerlRequire. if i want multiple mason sites i have to dig back into that perl script. certainly not difficult, but kinda irritating, and takes more effort to maintain, especially across multiple machines. Before we determine whether to advocate we need to term what and how to advocate. agree! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Gerald Richter wrote: I know that S.u.S.E. Linux (at least the german version) include a Apache with mod_perl as DSO ( but I never have tried it, I always compiled Apache/Perl/mod_perl etc. from the source), but they neither have included any of the Apache::* modules or Embperl/Mason/ASP/AxKit etc. i just installed suse 7.0 yesterday. i was psyched to find that i could install mod_perl (dso) with yast. i then fired up the cpan shell and installed Bundle::CPAN, Bundle::LWP, and HTML::Mason. then i had to create my mason handler.pl and do some httpd.conf tweaking. then i restarted and tried accessing the page under mason. result: "document contains no data" dialog in my browser, and no msgs in the error log, even under LogLevel error. commented out the mason lines in httpd.conf, restarted, and lived with flat html files. wasted 30-60 mins that i could have used to do my actual work. I could try to contact them and ask if it's possible to include more of the Apache modules and maybe the guide. please do! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, brian moseley wrote: i don't have figures, but from experience i know - once i've compiled httpd, i have almost no real configuration work to do with php. on the other hand, if i want to set up mason, i have to write 10-20 lines of perl code and access them with PerlModule or PerlRequire. if i want multiple mason sites i Well, in the future there will be a Mason::Dispatcher (or something) module to replace the custom code, at least for simpler cases. This would be _greatly_ helped along if somebody would respond to the question I posted a week or so back about the seg faults I was getting when I started working on a custom config system for Mason. Right now I'm kind of stalled on that. -dave /*== www.urth.org We await the New Sun ==*/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
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? _ 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: RFC: mod_perl advocacy project resurrection
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. 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. -- 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
i don't have figures, but from experience i know - once i've compiled httpd, i have almost no real configuration work to do with php. on the other hand, if i want to set up mason, i have to write 10-20 lines of perl code and access them with PerlModule or PerlRequire. if i want multiple mason sites i have to dig back into that perl script. certainly not difficult, but kinda irritating, and takes more effort to maintain, especially across multiple machines. That's what I always tried to avoid within the configuration of Embperl. I have tried to keep it as simple as possible for the first start. If you have mod_perl up and running, you just tell Apache to handle for example .epl files by HTML::Embperl and your are done. (exactly 6 lines to copy and paste form the Embperl docs into yout httpd.conf ), but as I understand Jonathan he (and Mason) has a slightly other intention in this area. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
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. I see a suitable target there ... maybe a SRPM bundling: Apache + mod_perl + libapreq + DBI + DBD::Mysql + HTML::Embperl + Apache::ASP + Template Toolkit ... I guess it's important that we build a SRPM so the build sequence uses the local perl intallation martÃn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
kevin montuori ([EMAIL PROTECTED]) said something to this effect: David Hodgkinson writes: prebuilt solves the problem nicely for people running linux; however, that's not everybody. i'm sure there are sun shops out there without the sysadmin expertise to download and compile mod_perl properly. i'd rather see the configure/compile process simplified than try to provide binaries for a dozen platforms -- that would allow the folks who'd be tied to compiling each new release to do more interesting and profitable things. Perhaps the solution is a complete, precompiled package, something that has Perl, Apache, mod_perl, and all the required modules prebuilt, in various formats: RPM, deb, tgz, Solaris pkg, and just regular tarballs. ActiveState has a generic, relocatable tarball of ActivePerl that can be moved around. It's very nice -- simple to install, answer a few questions, and the whole things gets put where you want it. With a handful of maintainers and a lot of diskspace, a number of configurations can be created. This is something I'd be willing to devote some time to. If anyone finds a home for something like this, consider me a volunteer. (darren) -- It has long been an axiom of mine that the little things are infinitely the most important. -- Arthur Conan Coyle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, Dec 05, 2000 at 08:26:35PM +, Matt Sergeant wrote: 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. IMHO, it shouldnt be that difficult if you make some good assumptions. For example, how difficult will it be to maintain the following package: 1. Assume Perl 5.5.3 OR 5.6.0 2. Assume latest Apache and static mod_perl 3. Assume latest Apache::DBI, Apache::Session, 4. Assume latest HTML::Mason (I cant speak for the others, yet) 5. Assume latest MySQL Now, with the above, I think we can maintain a basic demo, templating system with session management using Apache::DBI fairly easily. Ajit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Ajit Deshpande wrote: On Tue, Dec 05, 2000 at 08:26:35PM +, Matt Sergeant wrote: 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. IMHO, it shouldnt be that difficult if you make some good assumptions. For example, how difficult will it be to maintain the following package: 1. Assume Perl 5.5.3 OR 5.6.0 2. Assume latest Apache and static mod_perl 3. Assume latest Apache::DBI, Apache::Session, 4. Assume latest HTML::Mason (I cant speak for the others, yet) 5. Assume latest MySQL Now, with the above, I think we can maintain a basic demo, templating system with session management using Apache::DBI fairly easily. I can only suggest you try it as I speak from experience. -- 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!)
Everybody This whole call for mod_perl advocacy is definitely a good thing. But we're not going to get anywhere unless we understand the problem in detail. We can run around all we like talking numbers and touting the virtues of mod_perl but it's not going to actually do anything unless we address some fundamental issues. I don't claim to know the answers to these problems, but I do think I can at least start the ball rolling the right direction to get others thinking about what next. If we're on this list, there's a good chance we think we have a good understanding of mod_perl. Or at least a good understanding of the parts of the massive mod_perl beastie that we use. I use it all day every day but don't claim to know anything about Authentication, for example. I'm sure I could read the chapters in the eagle book and figure it out, but I don't know anything about it now. So, making that assumption, I want to bring up a few issues that I see as crucial. 1. We are worried that mod_perl is not being adopted as a server technology in enough places. This is actually TWO problems, not one, and to treat is as one is missing the point. There are TWO different kinds of developer out there. The first is someone who is probably not a programmer by trade, but has picked up CGI and/or PHP/ASP programming from a "21 days" book or by reading through examples. There are a number of reasons why *these* people have not jumped all over mod_perl... I'm sure we all know what those reasons are.The second group of people are *engineers* (or *developers*). These people need something different out of mod_perl. They need good docs, examples, stability, community support, and FOUNDATION CLASSES (more on this later) 2. Perl Let's face it, we love Perl, but a lot of people don't, because *they don't understand it*. Remember, a lot of people might have looked at Perl 4 when it was a disastrous hodgepodge and not looked at it since. Perl 5 is an infinitely better language than 4, but most people don't know that. In order for Perl to be acceptable in larger institutions with an already-established software engineering group, changes to Perl itself need to be made. See more below. 3. Installation/setup Ok, so if you have Linux, it's a piece of cake... download all the sources, 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 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. 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. 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. which brings me to... 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 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... 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. -- 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!): * 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... * We "homogenise" some foundation classes. This means we create a *suite* of classes that have consistent API, are designed together as a framework,
Re: RFC: mod_perl advocacy project resurrection
On Tue, Dec 05, 2000 at 04:14:13PM -0500, darren chamberlain wrote: Perhaps the solution is a complete, precompiled package, something that has Perl, Apache, mod_perl, and all the required modules prebuilt, in various formats: RPM, deb, tgz, Solaris pkg, and just regular tarballs. Exactly, and one has to make sure that perl is in the prebuilt package as well, probably even using a seperate path from the normally used perl locations, for example /usr/local/apache/perl for the perl installation. It is crucially important to have all of apache, apache modules, mod_perl and perl moduless built using a exactly the same compiler and a coherent set of compiler flags. -- Jens-Uwe Mager HELIOS Software GmbH Steinriede 3 30827 Garbsen Germany Phone: +49 5131 709320 FAX:+49 5131 709325 Internet: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Ajit Deshpande wrote: IMHO, it shouldnt be that difficult if you make some good assumptions. For example, how difficult will it be to maintain the following package: 1. Assume Perl 5.5.3 OR 5.6.0 2. Assume latest Apache and static mod_perl 3. Assume latest Apache::DBI, Apache::Session, 4. Assume latest HTML::Mason (I cant speak for the others, yet) 5. Assume latest MySQL Now, with the above, I think we can maintain a basic demo, templating system with session management using Apache::DBI fairly easily. fwiw, those are exactly the components the current version of ao supports out of the box. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
I think the issue is Perl for web applications advocacy rather than mod_perl advocacy. If more people thought using Perl for web apps was cooler and easier than using PHP, then they would use Perl and then graduate to mod_perl when they were ready. As it is, PHP has 1-up on CGI/Perl. PHP is FAST while still having an easy programming model. Having an easy programming model was Perl's claim to fame and why web apps fluorished in CGI/Perl. But PHP added one thing -- speed -- and they are taking it all away from Perl. The problem is mod_perl is not easy. Make a CGI/Perl solution for speeding up CGIs EASY and you will find people migrating back from PHP to Perl. Attending the PHP talks at ApacheCon/Europe, if there was one thing I found, PHP as a language is still REALLY new. PHP4 is the first really professional version of PHP, PHP3 is filled with a lot of skeletons. And I heard people still arguing about PHP4's language merits. Rasmus posted on BUGTRAQ the other day about some security problems with PHP scripts coming up (there have been several in the last week)... He posted that anyone running the scripts should upgrade to PHP4. Yet people are still finding it hard to upgrade to PHP4. So those people will have to go through hoops to shutdown security problems in their public domain PHP apps? Larry Wall was a genius in creating a great language with ease of expression. But we didn't carry the torch to make it fast and easy. By the way, I *LOVE* SpeedyCGI and mod_speedy. I forget who mentioned it to me at ApacheCon/Europe, but THANK YOU SO MUCH. For those of you that have not seen the project, please try it out. It makes speeding up CGI/Perl almost trivial. And it's definitely an ISPable solution because it plugs into Apache's CGI mechanism (non of the annoyance of giving plain users control over handlers). And oh yeah, SpeedyCGI is web server independent. It works just as well on Netscape (which is where I had to use it on a client site). The model is similar to FastCGI, but SpeedyCGI is trivial to setup unlike FastCGI which requires modification to the app. At 09:22 AM 12/5/00 -0800, Paul wrote: --- Stas Bekman [EMAIL PROTECTED] wrote: . I see two main streams: 1) Online zines. 2) Conferences. Apache.org has a whole subsection devoted to mod_perl Any idea what it would take to get a link there from webs like tpj and Perl.com? I was thinking that perl.com has a nice series of articles going for newcomers to the language, and Mark Jason-Dominus' series of red-flag articles has certainly been worth a read; wouldn't a less generic article series for less-new users interested in perl topics like Apache be worth space and a link? I've seen links to specific high-profile uses like the Human Genome Project as Perl advocacy. Wouldn't mod_perl be worth an ongoing link page in that right, perhaps with discussions of sites handling thorny problems? Or am I behind the times on that one? I'd even volunteer to write a few articles, though I hardly consider myself qualified to teach anything more than the basic concepts. I'm still on the steep side of the learning curve for designing effective and efficient subsites with handlers and some Embperl, but our shop has some odd needs that mod_perl seems built-for, and I do love to talk comments? __ 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] __ 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
Certification's are really hard and really expensive to do and pretty much crap even done well. We don't want anything to do with it. (IMO) - ask If you want to check if someone's certifiable, just search for their name in the archives of this list. Anyone you would want to hire has probably contributed something here. No pun intended, BTW. -- Tom Lancaster Red Hat, Inc. Web Engineer(415) 777-9810 x 228 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
This is exactly why someone experienced in training (ie Randal/StoneHenge) would hopefully be the ones to take the torch on this. If there's anyone I would trust a certification from, it would be them. At 02:07 PM 12/5/00 -0800, Ask Bjoern Hansen wrote: On Tue, 5 Dec 2000, Stas Bekman wrote: [...] May be we could organize some certification classes, to give more PR to mod_perl. Certification's are really hard and really expensive to do and pretty much crap even done well. We don't want anything to do with it. (IMO) - 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] __ 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 (and a proposal!)
On Tue, 5 Dec 2000, kyle dawkins wrote: * 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. Please take a look at: Alzabo (alzabo.sourceforge.net) - my own project Tangram (www.tangram-persistence.org) Those two are both very ambitious in terms of multiple DB support and complete abstraction. There are a number others that in a similar vein that are less ambitious (IMO): Class::DBI DBIx::DBSchema BingoX::Carbon DbFramework Those are all on CPAN. Of all of them, Tangram is by far the most mature. It is also actively maintained. I know that the first three on the bottom list, as well as Alzabo, are also being maintained. -dave /*== www.urth.org We await the New Sun ==*/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Gunther Birznieks wrote: I think the issue is Perl for web applications advocacy rather than mod_perl advocacy. If more people thought using Perl for web apps was cooler and easier than using PHP, then they would use Perl and then graduate to mod_perl when they were ready. well said. As it is, PHP has 1-up on CGI/Perl. PHP is FAST while still having an easy programming model. Having an easy programming model was Perl's claim to fame and why web apps fluorished in CGI/Perl. But PHP added one thing -- speed -- and they are taking it all away from Perl. well there's also the in-core support for things like database access, imap, etc etc. it's very easy to go to the php manual and look up the api for interacting with these services. you don't have to go to some component archive, look for something that suits, choose between 3 or 4 components that all do the same thing but in different ways, figure out how to configure the thing and work it into your build, etc. The model is similar to FastCGI, but SpeedyCGI is trivial to setup unlike FastCGI which requires modification to the app. yeah, one of the main goals of AO is to be portable between mod_perl, FastCGI, SpeedyCGI and other process models. app writers should be able to assume that the servlet environment provides a standard set of services without having to understand HOW, if that's their choice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Stas Bekman wrote: [...] May be we could organize some certification classes, to give more PR to mod_perl. Certification's are really hard and really expensive to do and pretty much crap even done well. We don't want anything to do with it. (IMO) - 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]
