Re: Fw: Re: mod_perl presence at OSCON (and other CONs) is at danger
On Tue, 8 Jun 2004 [EMAIL PROTECTED] wrote: My 2 cents is that mod_perl lacks an established application server/tookits so for a serious web application, programmers have to rely mostly on the original API to get the full benifit. While there sevearl great application tools like mason, ePerl, TT etc., yet, none of them is as established as php at the moment (in the sense: easy to write, support, coder community, code samples etc.) Uh, both Mason and TT have large active communities, lots of docs, books about them, code samples. ePerl is basically dead and all references to it should be abolished, since it only serves to confuse people. Perrin, maybe you could update your templating comparison article to remove things which have gone stale in the intervening years (ePerl Apache::XPP, I think). -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/ -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
RE: mod_perl presence at OSCON (and other CONs) is at danger
On Wed, 9 Jun 2004, Todd Cranston-Cuebas wrote: programmer. However, I do recruit a lot of perl programmers! What isn't really being discussed is that fact that new programmers often work with whatever technology allows them to cheaply get sites up and running on the web. Do a Yahoo search on PHP web hosting and you get 15.9 million links. Do the same search for mod_perl web hosting and you get 374,000. Still a lot, but you get the point. Until people can pick a cheap, reliable, and well-known hosting service where mod_perl is one of the main options, you limit your ability to attract new programmers. Go after the hosting companies with a complete mod_perl package that will be attractive to their clients. You might convince people if they had mod_perl as an easy choice (??). Perhaps I'm being a bit too simplistic, but I really like to recruit the young, talented, and eager people. I find they often use the tools that present themselves to them at the right time in their growing career. Dear Todd, I'd like to work at TickerM4st3r because I am a really experiunced PERL programmer. I used mod_perl with my hosting company and wrote a great program that takes a form and mails it to me. I also wrote a wicked cool hit counte.r I bet you could use that sort of stuff over at TicketM4st3r, right? Also, I know sysadmin stuff like how to use FTP! You get my point ;) Places like TicketMaster, which are working on _real_ apps, are not hiring people whose last experience was throwing together a few scripts for their personal web page. You want people who actually know lots of stuff, and have done interesting work. While mod_perl is harder to get started with, even when using Mason or TT, the effort required to get those things running forces you to actually learn something. Learning is a good thing, and makes you a better programmer. Yes, PHP is out there a lot, but there is still plenty of _serious_ mod_perl work being done, and that's the kind of stuff I'm interested in. If people want to get started with mod_perl, I'd recommend the following steps: - Learn Perl write some plain vanilla CGI stuff with Perl. Maybe learn to use Mason or TT or some other templating system via CGI. - Use Perl to write some non-CGI stuff, so you're not just a one area programmer. - Learn a bit about setting up Apache on your platform of choice. Set it up. - Get mod_perl installed. - Now go read about Apache::Registry and get some of your vanilla CGI to run under it. - Now read the mod_perl Cookbook, Stas Eric's book (or the online guide), etc. Yes, there are many steps here, but each one actually gives you _useful_ knowledge. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/ -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Fw: Re: mod_perl presence at OSCON (and other CONs) is at danger
Dave Rolsky wrote: Uh, both Mason and TT have large active communities, lots of docs, books about them, code samples. I agree. There isn't much sense in writing a new toolkit from scratch when you look at the stuff on this page: http://perl.apache.org/products/app-server.html Many of these have significant user communities. Things like PHP or J2EE look like a single integrated thing from the outside, but when you scratch the surface you discover that developers who use them are having the same discussions that we have about which templating tool to use (yes, even with PHP), and how to deal with databases and sessions. ePerl is basically dead and all references to it should be abolished, since it only serves to confuse people. Perrin, maybe you could update your templating comparison article to remove things which have gone stale in the intervening years (ePerl Apache::XPP, I think). Yes, and I need to replace HTML_Tree with Petal as well. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
I just read through this entire thread and picked an entry point for my response kind of randomly, but I do want to address this issue, because I also feel that it's very important. I've been coding Perl since '95...blah, blah..blah. MP and other Perl-related server-resident technologies have always been somewhat of a mystery. Never got the airplay that PHP et al has received. Always appeared to be 1) very low-level, 2) difficult to configure, and 3) prohibitively arcane, even to those of us who have been writing CGI's in Perl for years. I've now been emersed in MP/Mason now for the past several months. It hardly hurt at all. Basics Tenets of MP PR == 1) You know Perl and you can leverage that with MP/Embeded Perl/etc, and tap into the vast Perl technical and human resources that are already out there. 2) You're already using Perl, and can reuse what you've already got with MP. 3) MP is real, and getting value out of it is closer than you think. Issues of installation, configuration, and development are well-documented and easy to find. 4) As facile, powerful, and extensible as is Perl, so is MP. It's everything great about Perl plus everything great about Apache. Promoting MP Promoting Perl -- two different things. == On Tue, 2004-06-08 at 10:55, Frank Wiles wrote: In particular, I would say it's a mistake to think that mod_perl specifically needs PR. There is no important difference between promoting mod_perl and promoting Perl in general. Perl is mainstream. Perl is used by every SA, many users, and quite a few CGI hackers. It's installed, yea required for installation on every Linux distro (I didn't check, but...) MP is not, but it could be. Perl and MP address different domains of problems, really. Perl does everything...MP puts Perl on the web in a robust, professional-grade way. MP is the one that is the poor stepsister in the Perl and Apache equations. MP needs to be a focus of this awareness raising. MP Community Contribution = I agree that there is a need for more involvement from the MP community in getting the word out and there have been many good suggestions, including more articles in all of the major info outlets (the *nix, web server, and Perl sites and pubs). But the Greatest Gift of All: An MP Solutions Map == I think that perhaps the single resource with the greatest impact that we can provide to new users is a map of the available technologies/approaches to providing solutions using MP. There are many issues that we deal with in writing web applications, including sessions, persistence, logging, general how-to-think-in-MP, and installation and setup among others that could be layed out in such a way as to make these options and their implementations clearer. I would have loved to come across the document/site that provides a map of that stuff. I dreamed a dream of it and it said to me, So, you want sessions? Here are 3 modules that you can use to accomplish that. Here are the examples and links to each of those modules' docs. You need to understand caching. No problem. Here are 2 of the main approaches, including some gotcha's. Now, I see that you have a need for logging, so the most widely used approaches can be implemented with these modules, and of course, here's how it would look in your config and here's how you'd use it. Most of that stuff is out there, but it takes time to get to it. I think we need a MP Solutions Map. You know how it is: you recognize that you have a need, and either put it on your list to do when you get a chance to go find it, then try it, then implement it, or you recognize that you're going to f(#*$ yourself for the next 6 months by hacking a solution, so you do the homework to figure out how to do it right. The docs page on the MP home page seems like the right place for this to me. I have to do some of this anyway, so I can contribute. Count me in. My $.05US. -Eric. -- Eric Berg [EMAIL PROTECTED] http://www.bergbrains.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
But the Greatest Gift of All: An MP Solutions Map == I think that perhaps the single resource with the greatest impact that we can provide to new users is a map of the available technologies/approaches to providing solutions using MP. There are many issues that we deal with in writing web applications, including sessions, persistence, logging, general how-to-think-in-MP, and installation and setup among others that could be layed out in such a way as to make these options and their implementations clearer. I don't have much chance write mod_perl application in real life. but i do own Geoffrey Young's mod_perl developer's cookbook and web development with apache and perl which are great for mod_perl development and a lot good examples of mod_perl code can be found. with proper permission, I think that's something already exist that can be used for the mod_perl sample application/recipe you are talking about ( btw, great idea ! ). Qiang __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Stas (or anybody else) It so appears that in the last few years we get less and less mod_perl talks and tutorials at the big (non-YAPC) conferences. Do you know how many talks / tutorials were submitted ? Asking the other way round: Was it a problem of to less submissions or that the submissions didn't got accepted? I have submitted a tutorial about mod_perl and security, but it wasn't accepted. Since security is not so very special, I guess it was not accepted, because the oscon people didn't expect so much interest in mod_perl? Gerald --- Gerald Richterecos electronic communication services gmbh IT-Securitylösungen * Webapplikationen mit Apache/Perl/mod_perl/Embperl Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice: +49 6133 939-122 WWW:http://www.ecos.de/ Fax: +49 6133 939-333 --- ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info --- -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Gerald Richter wrote: Stas (or anybody else) It so appears that in the last few years we get less and less mod_perl talks and tutorials at the big (non-YAPC) conferences. Do you know how many talks / tutorials were submitted ? I don't have that information. if you remember in the previous years some of us were asked to help choose the talks. In the last few years we are no longer asked to do so. Asking the other way round: Was it a problem of to less submissions or that the submissions didn't got accepted? I have submitted a tutorial about mod_perl and security, but it wasn't accepted. Since security is not so very special, I guess it was not accepted, because the oscon people didn't expect so much interest in mod_perl? As I'm not involved with the committee that makes the decisions I can't tell. But I do know a few folks that have submitted talks and they weren't accepted. I know last year I submitted a tutorial and a talk, and only the tutorial was accepted. This year I didn't even bother to submit a talk proposal. I suppose other people get discouraged too and submit less. I could be wrong, as this is all handwaving. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
--- Jie Gao [EMAIL PROTECTED] wrote: It appears easy to beginners, but as server admin, I find it a nightmare for beginners to play with it without knowing what's involved. So the marketing strategy for mod_perl should be very different. One can do so much more with mod_perl. I don't think that's such a good idea. You speak of your concern with what beginners (developers on a shared host) can do with PHP, but this concern is much greater with mod_perl, because mod_perl gives a developer access to so much more. In that regard, PHP is safer from a server admin perspective. I think the better approach is to advocate mod_perl's strengths from a developer's perspective, since that is where it thrives (in my opinion). PHP is like a bird in a cage in some respects, which is great if you're trying to keep an eye on the bird. But, if you're the bird, you'd rather be free to fly around. Chris -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
I am not responding solely to your post here, but also to several other points I saw brought up. Geoffrey Young wrote: Perrin Harkins wrote: On Tue, 2004-06-08 at 18:47, Chris Shiflett wrote: well, I think it really depends on what you want to accomplish. all the above really seems like just a perl versus php (or $web_language) debate: both run on a number of different server platforms, have strong followings, and are proven scalable and "enterprise" (sorry for throwing out that term, but you get the idea :). in the end, arguments like the above are very, very important ones for us as perl programmers, but I don't think they help mod_perl prosper as a technology, which is what I'm interested in :) while I realize I'm in the minority with this view (and perrin and I have had this discussion/friendly disagreement before :) what _I_ like about mod_perl cannot be satisfied by anything other than mod_perl - I like the Apache API, and I would prefer to use it in conjunction with Perl rather than mess around with C (or even something like apache_hooks, since I don't know php :) for those that share a love for this particular aspect of mod_perl and have a desire to see it prosper, nothing else will really do. if mod_perl is just a means to performance ends similar to the other technologies you mention, it would be simpler and more efficient to strip mod_perl down to just an embedded interpreter and support development of just Registry.pm and the minimal API it requires. I think mod_perl more than that, and that is why I feel beaten down when nobody seems to care about mod_perl for what it really is, or people say you can just swap it out for FastCGI or something and things move on. that's when I feel like I'm wasting my time. I apologize in advance if because of my mass snipping I've taken you out of context. While I think you are right that mod_perl is more than that, I do wonder what people really care about. I have to say that although I love the speed of mod_perl, I find that for most tasks I have to do, I do not require even a persistant perl interpreter. I just like using Perl. I've only used the Apache API a few times and that was when I was trying to emulate Sybase's WebSQL and hoping to convert all our Sybase WebSQL apps to mod_perl at a past organization I was at. If it weren't for the peculiar ways in which WebSQL did it's stuff, I probably would have just as soon run with Apache::Registry. So I suppose I would be in that camp that frustrates you. :) I like using Perl or mod_perl for web apps because I know that Perl can be used as a cron job, as a scripting language, as a glue, for sysadmin tools already written in Perl (eg log_accum.pl) etc. I feel as if I learn PHP then I would have to still learn Perl for the non-web stuff. So why not kill two birds with one stone? One thing I found interesting was Perrin bringing up the idea of different ways of using Perl. I still think that there is a key here. However, it's again I wonder about what is really mod_perl specific PR and what is perl specific PR. Unless I am mistaken, I think Bioinformatics was brought up in this mailing list as one possible class of apps to talk about here. Here actually, I am not sure mod_perl really shines relative to Perl. Bioinformatics apps tend to call algorithms or statistics that may run for such a long time that adding the small amount of time it takes for Perl interpreter to load on a reasonably recent Linux box is really not noticeable. It's nice to use mod_perl, but not something that makes people scream if mod_perl isn't on a typical bioinformatics web server which usually emphazises small number of PhDs running complex algorithms. It has always seemed to me that mod_perl shines more for apps that are retail or heavy in usage where you need to accommodate many hits and each hit does something very small that would be terrible for a slow-down to occur (like amazon front page or a porn site). I am not sure if this is another "issue" about PR for mod_perl -- why use it if machines are fast enough to support plain CGI/Perl these days? Perl saved the Human Genome Project. mod_perl didn't, although maybe mod_perl saved more than one slow webstore? With that said about bioinformatics in particular, I think I would carry the idea of classes of apps one step further. I think the key to mod_perl being noticed is really about the apps not about touting the technology. It's one level of PR to claim that a website that is popular like Whatever.com is using mod_perl, but quite another for whatever.com to share their code so that others who want to do the same thing download the code and use mod_perl because the app said "use mod_perl". To me, it seems PHP has a lot more apps touting the use of PHP (even if indirectly) than mod_perl apps do. There are a lot of free Perl apps out there, but mod_perl apps on perl.apache.org tI count about 15 apps total (not counting
Re: mod_perl presence at OSCON (and other CONs) is at danger
Hi, In Advanced Perl Programming, under the heading the case for scripting. That is something that I think would fit in very well in a talk. Lots of people know there are an endless number of very cool impressive things you can do with Perl and mod_perl. The amazing one liners, the tricks that make people slap their head. But it seems to me the idea of the big model, the whole structure that will encompass everything you do in your organization is what many are striving for, so cool things are looked at almost as negative. IMHO that is why you see big corp. that use mod_perl using Mason, at least as a starting point. I think the other aspect of mod_perl that I would want to push very hard is the deep hooks into Apache. Just as a small example of something I have not yet figured out, but am pretty sure I can find a way with mod_perl, I want to capture STDERR and redirect it to an in memory file There are a bunch of cpan module that do something like this, but I started to wonder about how that works with Apache itself since STDERR gets written to the error_log(please don't give me the answer BTW) :) The main point I am trying for here in a clumsy way is that I am not sure how many people developing web apps with other tools are thinking in terms of how to alter the way Apache behaves but rather are thinking about how their app deals with Apache. I think that is a massive difference and a good expression of the power of mod_perl. Sorry for the blathering, I don't have much time to write this kind of stuff at work, but I am hoping this might provide some ideas. Thanks, Eric At 10:45 AM 6/8/2004, Randal L. Schwartz wrote: Stas == Stas Bekman [EMAIL PROTECTED] writes: Stas Because someone needs to do the talk. Java XML developers have a Stas pretty big development team, so they have resources/tuits to do that Stas kind of things. The mod_perl dev team is so much smaller and hardly Stas manages to do the development and support, and there are no tuits Stas remaining for PR. That's why it'd be great if someone who is good at Stas PR could step up and make things happen. I was surprised when of all 12 things I submitted for OSCON, one of the two accepted was my dinky little mod_perl talk. And it's not even in the Perl track, but in the Apache track. I'll do everything I can to continue to beat the drum about mod_perl. I've been reading this thread with interest, but if anyone wants to ensure that I'll cover a particularly interesting point in my talk, please email me. -- 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! -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
--- gunther [EMAIL PROTECTED] wrote: www.mod_perl.com (doesn't exist) www.mod_perl.org (doesn't exist) A small point, and I would have to double-check, but I don't believe underscores are allowed in domain names. You'd want to replace those with hyphens. A Google search for mod_perl gives me the mod_perl Web site, the user guide, Stas's book, and Geoff's book, in that order. Those are all pretty good resources, and this is where people looking for mod_perl information are likely to end up. I think the more important issue is making mod_perl something for which people search for information, because they've already heard about it through other means. Chris -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
[EMAIL PROTECTED] wrote: The only place where the C API overrides the Perl API in mp1, IMHO, is for the configuration process. To do somehow a complicated configuration in Perl seems even more difficult than in C. Well, maybe I should sit down and read those chapters in the 3 books again :-) In mp2 this is all done in Perl and it's *easy*: http://perl.apache.org/docs/2.0/user/config/custom.html -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Eric wrote: In Advanced Perl Programming, under the heading the case for scripting. That is something that I think would fit in very well in a talk. Lots of people know there are an endless number of very cool impressive things you can do with Perl and mod_perl. The amazing one liners, the tricks that make people slap their head. But it seems to me the idea of the big model, the whole structure that will encompass everything you do in your organization is what many are striving for, so cool things are looked at almost as negative. It's as if someone's looking for an integrated transport solution and you show them a car that's great for doing wheelspins. IMHO that is why you see big corp. that use mod_perl using Mason, at least as a starting point. I think the other aspect of mod_perl that I would want to push very hard is the deep hooks into Apache. Just as a small example of something I have not yet figured out, but am pretty sure I can find a way with mod_perl, I want to capture STDERR and redirect it to an in memory file There are a bunch of cpan module that do something like this, but I started to wonder about how that works with Apache itself since STDERR gets written to the error_log(please don't give me the answer BTW) :) Oops. Nearly did :) The main point I am trying for here in a clumsy way is that I am not sure how many people developing web apps with other tools are thinking in terms of how to alter the way Apache behaves but rather are thinking about how their app deals with Apache. I think that is a massive difference and a good expression of the power of mod_perl. I'm sure that's true but it's still a justification for mp that plays best with geeks. The majority of web applications that people are actually developing (as opposed to the ones they aspire to) are actually fairly simple things and they're often created by developers who come from a web design background rather than a computer science one. They can generally do everything they need with PHP or ASP. I'm sure one of the reasons for the popularity of Perl as a command line tool is the low cost of entry: within a few minutes of seeing your first Perl script you can knock up a useful five liner of your own. For the web PHP and ASP occupy that space. They're probably already installed so you can dip your toe in the water with a simple ?php echo Hello, World ? and build from there. -- Andy Armstrong -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
docs (was Re: mod_perl presence at OSCON (and other CONs) is at danger)
Stefan Loones wrote: [...] Then about the documentation: [...] Stefan and a few other folks have voiced a few concers about docs. I'll try to address those here: 1) docs need to be improved and reorganized. Well, docs need to be written. It's easy to suggest things, one needs to actually write docs. When was the last time you submitted a doc patch? 2) docs need to have user comments. I'm not sure it's a good idea. We already have a way too much documentation. Instead of making it even harder for users to find things, one should take the existing docs and improve them, rather then dump random comments in there. If you want to add a comment, that means that something is not clearly explained. So take your time to try and reword the existing docs to make them more clear. It's not the quantity but the quality that matters. 3) 2.0 docs are lacking and we don't want to go and read mp1 docs for areas not covered by mp2 docs. so far Randy Kobes and I are the only ones writing those docs (with help from Philippe, Geoff and a few other folks). At the moment you already have 400 pages (some are still unpolished) of API docs [1] and 300 pages of user docs [2] and those are improved daily. I'm writing docs mainly for new mp2 things, which are different from mp1. If you want to see mp1 docs ported to mp2 docs, you need to send doc patches. Things won't appear out of thin air, one needs to actually do the work. [1] http://perl.apache.org/docs/2.0/api/api_2.0.pdf [2] http://perl.apache.org/docs/2.0/user/user_guide_2.0.pdf If you would like to get involved with docs, the commit access is easy to get. Just start posting patches and show committment, and then you will be able to fix things directly... Here is again the info on how to contribute to docs: http://perl.apache.org/download/docs.html http://perl.apache.org/contribute/index.html I'm looking forward for your doc patches ;) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Eric wrote: I think the other aspect of mod_perl that I would want to push very hard is the deep hooks into Apache. Just as a small example of something I have not yet figured out, but am pretty sure I can find a way with mod_perl, I want to capture STDERR and redirect it to an in memory file There are a bunch of cpan module that do something like this, but I started to wonder about how that works with Apache itself since STDERR gets written to the error_log(please don't give me the answer BTW) :) when you reach the point when you want an answer, it's right there in recipe 16.6 in the mod_perl developer's cookbook. the code is online as well http://www.modperlcookbook.org/code/ch16/Cookbook-DivertErrorLog-0.01/ :) The main point I am trying for here in a clumsy way is that I am not sure how many people developing web apps with other tools are thinking in terms of how to alter the way Apache behaves but rather are thinking about how their app deals with Apache. I think that is a massive difference and a good expression of the power of mod_perl. I'm really not into self-promotion, but this is pretty much to point of view the MPDC takes throughout. but unfortunately the book has had only a limited following. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
--- Jie Gao [EMAIL PROTECTED] wrote: I also likes Stef's idea about adding user comments for doc. hope it can happen. hmm, does mod_perl still have problem running for virtual hosts? people choose php over cgi for obvious reason. Problem with virtual hosts? Like what? here http://perl.apache.org/docs/general/multiuser/multiuser.html so people will chose php over mod_perl under this circumstance. but when php can run the small/medium project just fine, why people will choose mod_perl over others anyway? other than.. oh,i love perl and i know apache. I am not bashing mp here. I would love to know the answer and see it up in the doc if possible. cheers, James. __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Domain Name PR was Re: mod_perl presence at OSCON (and other CONs) is at danger
Chris Shiflett wrote: --- gunther [EMAIL PROTECTED] wrote: www.mod_perl.com (doesn't exist) www.mod_perl.org (doesn't exist) A small point, and I would have to double-check, but I don't believe underscores are allowed in domain names. You'd want to replace those with hyphens. Right, and that brings up another thing I want to change! :) Actually you are right. Technically underscores are not allowed although I think some DNS servers and clients may support it (esp. from the microsoft world?). Even though the original? DNS RFC supports hyphens, I remember that many years ago when I worked for red-cross.org, the hyphen worked OK on the server and many clients, but some email clients didn't like the hyphen at all and said it was an invalid domain name if someone wanted to send email to us. So eventually it was changed to redcross.org. But if some clients do support underscore, since mod_perl is frequently written with an underscore, may as well get that domain name too in case the client supports it and someone actually types www.mod_perl.com or www.mod_perl.org. But still having modperl.com as a primary project-name related domain name would be there for people who can't type _. Regardless, this part (as I think you meant) is just a detail where the main point shouldn't necessarily be lost as discussed below. A Google search for mod_perl gives me the mod_perl Web site, the user guide, Stas's book, and Geoff's book, in that order. Those are all pretty good resources, and this is where people looking for mod_perl information are likely to end up. I think the more important issue is making mod_perl something for which people search for information, because they've already heard about it through other means. You are right, but the point is to improve the PR. I am not contending that people cannot find what they are looking for. I could find pubmed's real URL by searching on google also (following my example of www.pubmed.com instead of the long national library of medicine URL). But the point is one of convenience and perception. [Convenience] It's convenient to remember that major projects or entities generally have a domain name that links to them. Do you think www.newegg.com would be satisfied as www.web66.com/~newegg? (or substitute whatever you like bestbuy.com, pizzahut.com, and even... perl.com etc...) The fact that you have to remember perl.apache.org instead of modperl.com is not so convenient unless you go to the site all the time or have it bookmarked. Most people on this mailing list probably do both so maybe you don't see this being a problem, but to the infrequenters, it's nicer to not have to remember what the "trick" was (Oh yeah, mod_perl is an apache project, so it's not it's own domain name, it's perl.apache.org). I am also not saying to give up perl.apache.org. www.modperl.com could simply redirect to perl.apache.org. [Perception] I could be wrong, but I think the message of key www.modperl.com URL belonging to a mere single book on the market sends a message that is not optimal to how the mod_perl community should present itself.. I perceive a project where a couple people (even if they are people without whom mod_perl wouldn't exist! :) ) taking the www.modperl.com domain name for a book rather than allowing the project itself to utilize that domain name is not serving the community at large. At best it is not convenient for the community at large, at worst, it sends a message of fragmentation that the project couldn't even get it's own domain name and "looks like" some private couple of people took it out from under the community (regardless of whether this is true or not). I could understand why the authors would want to take the domain name for themselves because it will give them a lot more hits (which arguably increases the sale of their book), but I would argue that mod_perl books as a whole will sell better in general if the project itself has the added convenience of it's own primary domain name. Enhancement of PR of mod_perl is good for everyone who sells a mod_perl book including the original authors (I would think). [How Important Is This...Really?] Anyway, I am talking PR here. Many PR things are actually unnecessary to do. You could spend the next 5-10 years without www.modperl.com pointing to the real mod_perl website and it probably would only make a small difference, but still I think it would be a difference so I added it to the "to do list" of what I personally believe should happen to enhance mod_perl PR. It's OK if people disagree with me of course. :) :)
Re: mod_perl presence at OSCON (and other CONs) is at danger
Hi, FWIW IMO Speed, Flexibility, comprehension, Google_sex_appeal:) I find modperl cool. It would be useful IMO to promote by articles/board that contained everything from simple to complex usages for modperl catagorized by stage(s) used. (That way people can hit the ground running.) This might prod others to start to comprehend the vast spectrum of ways it is best of breed. I have nothing against PHP and can see its uses. (It has gone a long ways from Personal Home Pages). This might be usefully presented in a CPANish way on a central website. 3 out of 4 are already pretty apparent. Full comprehension seems to be the issue. I guess what I am trying to say is that perhaps it simply goes over many people's heads. Best Regards, [EMAIL PROTECTED] -- /* Security is a work in progress - dreamwvr */ # 48 69 65 72 6F 70 68 61 6E 74 32 # Note: To begin Journey type man afterboot,man help,man hier[.] # 66 6F 72 20 48 69 72 65 0001 // Who's Afraid of Schrodinger's Cat? /var/(.)?mail/me \? ;-] -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
One key point that the PR needs to address is the future of a programming toolkit. mod_perl allows people to write perfect MVC applications while other scripting toolkits like php or asp are hard in seperating algorithm from html presentation. Sorry if I am misleading, but if to make a big PR, we may change the strategy completely from the easy fast to the future standard, because php/asp are already fast enough while most new users or current php/asp users have rarely extreme cases where only mod_perl can do the job. But if we promote the MVC concept, they would have a second thought. This looks like that we give up competition with php/asp, but to go to the area where Java servlet works. ... my 2 cents. Pod Merl gunther [EMAIL PROTECTED] wrote: ... I could be wrong, but I suppose a positive way moving forward would be to resolve the following issues to generate more positive PR for mod_perl in the following summary: 1) Promoting classes of applications that use mod_perl eg Success stories for classes of applications that use mod_perl (maybe even bioinformatics) a once a month interview with someone using mod_perl successfully would make a nice repetoire of more stories. 2) Promoting applications that use mod_perl If you've written a useful app that uses mod_perl at your workplace, please see if your employer would consider allowing it to be open sourced. 3) Let's get the domain names in order. eg It's nice that Lincoln and Doug have had modperl.com all these ages, but now that their book has been out for years, it would be nice to give the URL back to the community and instead have their book use a more appropriate URL like modperlbook.com. Likewise for other URLs. 4) ISPs That support mod_perl This is a tough one but I think it would be interesting to know what supporting mod_perl means for the 50 ISPs on the list. Is there a way that they can share their secrets (ala #1) to encouraging other ISPs to support mod_perl. Can people evangelize the use of mod_perl on their servers? I suppose this may only happen if there are enough apps in #2 to force the ISPs to want to enable mod_perl by default though... 5) Create a google bomb whereby when web apps of mass domination is searched, perl.apache.org comes up. Then report the google bomb as a news item on slashdot. Thanks, Gunther .. ---BeginMessage--- I am not responding solely to your post here, but also to several other points I saw brought up. Geoffrey Young wrote: Perrin Harkins wrote: On Tue, 2004-06-08 at 18:47, Chris Shiflett wrote: well, I think it really depends on what you want to accomplish. all the above really seems like just a perl versus php (or $web_language) debate: both run on a number of different server platforms, have strong followings, and are proven scalable and "enterprise" (sorry for throwing out that term, but you get the idea :). in the end, arguments like the above are very, very important ones for us as perl programmers, but I don't think they help mod_perl prosper as a technology, which is what I'm interested in :) while I realize I'm in the minority with this view (and perrin and I have had this discussion/friendly disagreement before :) what _I_ like about mod_perl cannot be satisfied by anything other than mod_perl - I like the Apache API, and I would prefer to use it in conjunction with Perl rather than mess around with C (or even something like apache_hooks, since I don't know php :) for those that share a love for this particular aspect of mod_perl and have a desire to see it prosper, nothing else will really do. if mod_perl is just a means to performance ends similar to the other technologies you mention, it would be simpler and more efficient to strip mod_perl down to just an embedded interpreter and support development of just Registry.pm and the minimal API it requires. I think mod_perl more than that, and that is why I feel beaten down when nobody seems to care about mod_perl for what it really is, or people say you can just swap it out for FastCGI or something and things move on. that's when I feel like I'm wasting my time. I apologize in advance if because of my mass snipping I've taken you out of context. While I think you are right that mod_perl is more than that, I do wonder what people really care about. I have to say that although I love the speed of mod_perl, I find that for most tasks I have to do, I do not require even a persistant perl interpreter. I just like using Perl. I've only used the Apache API a few times and that was when I was trying to emulate Sybase's WebSQL and hoping to convert all our Sybase WebSQL apps to mod_perl at a past organization I was at. If it weren't for the peculiar ways in which WebSQL did it's stuff, I probably would have just as soon run with Apache::Registry. So I suppose I would be in that camp that frustrates you. :) I like using Perl or mod_perl for web apps
Re: mod_perl presence at OSCON (and other CONs) is at danger
folks, there is no need to quote 22K of text you don't quite use anyway :( Please quote only parts of the text you reply to, or don't quote at all. Thanks. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
folks, there is no need to quote 22K of text you don't quite use anyway :( Please quote only parts of the text you reply to, or don't quote at all. Thanks. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker Sorry. I thoguht I erased the checkbox include original message in the ATT web mail, but apparently not. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Domain Name PR was Re: mod_perl presence at OSCON (and other CONs) is at danger
gunther [EMAIL PROTECTED] 2004-06-09 16:42 But if some clients do support underscore, since mod_perl is frequently written with an underscore, may as well get that domain name too in case You can NOT buy from Registrars domain names with underscores in them. These ``domain names'' do not exist on Internet scale. Problem solved. -- Patrick. ``Never argue with an idiot. He'll drag you down to his level, then beat you with experience.'' -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
RE: mod_perl presence at OSCON (and other CONs) is at danger
At 9:51 AM -0700 6/9/04, Todd Cranston-Cuebas wrote: lot, but you get the point. Until people can pick a cheap, reliable, and well-known hosting service where mod_perl is one of the main options, you But it has to be more than mod_perl. mod_perl is far too low-level. Even Embperl or Mason require too much work to get started. It absolutely has to be a layer above that. You want something that provides the basic tools right up front, so that your typical web site (feedback forms, press releases...) is a no-brainer, and after that the user is hooked. What we could really use is a company that fills the RedHat/Cygnus space for Perl, pulling all the separate components together into a useful whole, and adding new glue where necessary. And for maximum leverage, part of that glue should be a mod_perl-based version of what's currently available in PHP, for use as a transition tool. It's not too late, but it's getting close. -- Kee Hinckley http://www.messagefire.com/ Next Generation Spam Defense http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Hi, Well at the very least you sold a book :) I have to admit, when I looked at that book the first time, I thought I pretty much knew everything in it, what BS that was! :) I did solve my problem on my own somewhat sloppy way, but the example you gave was very interesting too and I hope to make use of it soon. Thanks, Eric At 05:47 AM 6/9/2004, Geoffrey Young wrote: Eric wrote: I think the other aspect of mod_perl that I would want to push very hard is the deep hooks into Apache. Just as a small example of something I have not yet figured out, but am pretty sure I can find a way with mod_perl, I want to capture STDERR and redirect it to an in memory file There are a bunch of cpan module that do something like this, but I started to wonder about how that works with Apache itself since STDERR gets written to the error_log(please don't give me the answer BTW) :) when you reach the point when you want an answer, it's right there in recipe 16.6 in the mod_perl developer's cookbook. the code is online as well http://www.modperlcookbook.org/code/ch16/Cookbook-DivertErrorLog-0.01/ :) The main point I am trying for here in a clumsy way is that I am not sure how many people developing web apps with other tools are thinking in terms of how to alter the way Apache behaves but rather are thinking about how their app deals with Apache. I think that is a massive difference and a good expression of the power of mod_perl. I'm really not into self-promotion, but this is pretty much to point of view the MPDC takes throughout. but unfortunately the book has had only a limited following. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Perrin Harkins wrote: Stas Bekman wrote: It so appears that in the last few years we get less and less mod_perl talks and tutorials at the big (non-YAPC) conferences. And that's a bad trend. It certainly affects the number of mod_perl job offers, since those who decide which technology to choose for their next project go to those big conferences and chances are very high that they will pick the technology that had a dominating presense in terms of tutorials and presentations. I have seen both you and Geoff give talks at various conferences, and have always learned something new. I would recommend talks and tutorials by either of you to anyone interested in learning more about mod_perl. I don't see the same gloomy story in the conferences this year though. It seems likely to me that nearly every talk about web-related uses of Perl will talk about mod_perl in some way. Even Vivek's talk which has PersistentPerl in the title will probably mention whether or not the techniques are all equally applicable to mod_perl. mod_perl is no longer a new tchnology that people need lots of help to understand; it is now the accepted standard for building any serious web application in Perl. The result is that there is less talk about mod_perl itself and more about what people are doing with it. This is partly due to the work that you and others have done over the last few years: good books and on-line documentation are now available to teach people mod_perl, and even survey books like Perl Cookbook cover it. These days, nearly every web-related job posted on jobs.perl.org asks for mod_perl experience. That's a good sign of success to me, and is a lot different from how things were a few years ago. Thanks to you and Geoff for your ongoing efforts in support of mod_perl and this community. Thanks for the kind words, Perrin. And your contribution (and other folks) is not to be underestimated. I guess it's still important to make an effort to have mod_perl appear more in the media (e.g. articles, announcements), conferences, etc. But your viewpoint is interesting. It'd be really nice to have someone doing PR for mod_perl, like all those Java and PHP projects do. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
On Jun 8 Stas Bekman wrote: Perrin Harkins wrote: Stas Bekman wrote: It so appears that in the last few years we get less and less mod_perl talks and tutorials at the big (non-YAPC) conferences. And that's a bad trend. Maybe a BOF meeting? Like all good list posters, I researched this problem (mod perl bofs) and found that, historically at least, bof's are almost always informally organized and resist any type of formalization. For example look at: Long link: http://mathforum.org/epigone/modperl/leldbumblal/[EMAIL PROTECTED] same link tiny-fied: http://tinyurl.com/3y2ne Yet, being an optimist, I created a mod perl entry at the yapc kwiki. Kwiki BOF link: http://yapc.kwiki.org/index.cgi?BOF Back to working on my lightning-talk-poster, regards. Zenitram -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
It looks like this story made it to the use.perl.org front page. That's a goodness :) Jim Martinez wrote: On Jun 8 Stas Bekman wrote: Perrin Harkins wrote: Stas Bekman wrote: It so appears that in the last few years we get less and less mod_perl talks and tutorials at the big (non-YAPC) conferences. And that's a bad trend. Maybe a BOF meeting? Like all good list posters, I researched this problem (mod perl bofs) and found that, historically at least, bof's are almost always informally organized and resist any type of formalization. For example look at: Long link: http://mathforum.org/epigone/modperl/leldbumblal/[EMAIL PROTECTED] same link tiny-fied: http://tinyurl.com/3y2ne Yet, being an optimist, I created a mod perl entry at the yapc kwiki. Kwiki BOF link: http://yapc.kwiki.org/index.cgi?BOF It lacks a bit on details :) I probably won't make it to YAPC Europe this time, but if anybody wants to organize mod_perl BOF at OSCON [1] I'll certainly be there to answer any questions you may have. Geoff, Philippe and others might come too. But in any case you can always stop us in the corridor and talk. Don't be shy, just come and talk... [1] http://conferences.oreillynet.com/pub/w/29/bof.html -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
On Tue, 08 Jun 2004 06:19:41 -0700 Stas Bekman [EMAIL PROTECTED] wrote: ... [ big snip ] I guess it's still important to make an effort to have mod_perl appear more in the media (e.g. articles, announcements), conferences, etc. But your viewpoint is interesting. It'd be really nice to have someone doing PR for mod_perl, like all those Java and PHP projects do. I agree mod_perl needs more PR. I think we've got a great community of people to help on the mailing list, tons of great documentation, but lack in several areas: 1) PR announcements in general (When is the last time you saw mod_perl in the press?) 2) Online and magazine articles about mod_perl 3) HOWTOs on specific subjects 4) Small application examples with developer commentary. I think all of these are important and #4 especially for people new to programming or just new to mod_perl. If we had 4 or 5 small working applications online that had detailed commentary about specific mod_perl info, overall design decisions, how to properly layout code in a couple of different styles. How to layout your modules, objects, database schema/connections, optimizations, authentication, sessions, etc. it would go a long way helping people get started (or find betters methods than they currently use) in mod_perl. While I think the documentation and the various books on mod_perl are wonderful resources I think if we had a few mod_perl patterns online it would help new and experienced coders get a better handle on how mod_perl fits into the big picture of their application. What I'm thinking about is much like Perrin's great article about etoys.com, only with full working code and copious amounts of commentary about it. Since many of us will be in Portland for OSCON, maybe we should get together in person to discuss mod_perl PR in more detail? Perhaps even create a small group of people to help with PR much like the PostgreSQL group has recently done with their advocacy group. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org - -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
On Tue, 2004-06-08 at 10:32, Jim Martinez wrote: Yet, being an optimist, I created a mod perl entry at the yapc kwiki. Kwiki BOF link: http://yapc.kwiki.org/index.cgi?BOF Thanks! It looks like it should be on the front page with the other BOFs though. Maybe we could do it Thursday night before the big dinner. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
RE: mod_perl presence at OSCON (and other CONs) is at danger
That would rock. Count me in. I'd also be willing to take some of my free time and help out where possible, whether it be building some example sites, or whatever. Would be nice to have others scrutinize my style a bit, too. It might also be nice to have some sort of well organized knowledge base on or near the perl.apache.org site. A place where common issues or problems could have resolutions beyond the standard documentation. Here are some ideas for example scripts... Even though there may be modules out there that provide similar functionality, they might be good to help users better their knowledge about all the things that can be done with mp1/2. Figure it would be good to make some that reside in places other than PerlResponseHandler. Form submissions auth (w/ cookies) Basic auth with a file Basic auth with a db In mp2, a quick input validation filter would be cool. Session management w/ w/o ::Session Dynamic page content from a db and management of content? Maybe using xml/xslt? - and mp2 version using apache_xml to parse? ... -Original Message- From: Frank Wiles [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 08, 2004 9:56 AM To: Stas Bekman Cc: [EMAIL PROTECTED] Subject: Re: mod_perl presence at OSCON (and other CONs) is at danger Since many of us will be in Portland for OSCON, maybe we should get together in person to discuss mod_perl PR in more detail? Perhaps even create a small group of people to help with PR much like the PostgreSQL group has recently done with their advocacy group. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Kreimendahl, Chad J wrote: That would rock. Count me in. I'd also be willing to take some of my free time and help out where possible, whether it be building some example sites, or whatever. Would be nice to have others scrutinize my style a bit, too. It might also be nice to have some sort of well organized knowledge base on or near the perl.apache.org site. I think the infrustructure is all there, just need to fill in the gaps. A place where common issues or problems could have resolutions beyond the standard documentation. It's there already: mp1: http://perl.apache.org/docs/1.0/guide/troubleshooting.html mp2: http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html If things are missing, please post a doc patch. Here are some ideas for example scripts... Even though there may be modules out there that provide similar functionality, they might be good to help users better their knowledge about all the things that can be done with mp1/2. It should probably go here: mp1: http://perl.apache.org/docs/1.0/guide/snippets.html mp2: http://perl.apache.org/docs/2.0/user/coding/cooking.html Here is the info on how to post doc patches: http://perl.apache.org/download/docs.html http://perl.apache.org/contribute/index.html -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Hi!
On Tue, Jun 08, 2004 at 09:55:56AM -0500, Frank Wiles wrote:
I think all of these are important and #4 especially for people new
to programming or just new to mod_perl. If we had 4 or 5 small
working applications online that had detailed commentary about
specific mod_perl info, overall design decisions, how to properly
layout code in a couple of different styles. How to layout your
modules, objects, database schema/connections, optimizations,
authentication, sessions, etc. it would go a long way helping people
get started (or find betters methods than they currently use) in
mod_perl.
Last year at YAPC::Europe I did a tutorial in which I did what you proposed.
Unfortunalty the slides aren't really up do date and the server the
application was hosted on is currently not available (cause we're setting up
some new servers..)
But as soon as the server's back up (next week I hope) and as soon as I find
some time (this will probably take longer...) I can polish everything up and
add some links to the app and the slides from the mod_perl site. Or maybe
dump the slides and write a proper article.
You should be able to get the slides at http://domm.zsi.at/talks/yapc2003
(or if I don't get this URL to work in the next minutes at
http://domm.dev.zsi.at/talks/yapc2003). But please note that the slides are
a bit outdated and I would do some things differently now than I did when I
wrote them...
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
On Jun 8 Perrin Harkins wrote: On Tue, 2004-06-08 at 10:32, Jim Martinez wrote: Yet, being an optimist, I created a mod perl entry at the yapc kwiki. Kwiki BOF link: http://yapc.kwiki.org/index.cgi?BOF Thanks! It looks like it should be on the front page with the other BOFs though. Maybe we could do it Thursday night before the big dinner. Oh, I just followed the BOF link on the front page. There are other BOFs listed right below that link. My bad. I added a mod perl link on the front page, but it still lacks details. Maybe I should call it a stub. Later, Zenitram -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Perrin Harkins a écrit : On Tue, 2004-06-08 at 10:55, Frank Wiles wrote: I agree mod_perl needs more PR. I think we've got a great community of people to help on the mailing list, tons of great documentation, but lack in several areas: 1) PR announcements in general (When is the last time you saw mod_perl in the press?) 2) Online and magazine articles about mod_perl 3) HOWTOs on specific subjects 4) Small application examples with developer commentary. These are really two different things. The first two are more about getting the word out while the second two are about helping people with practical coding issues. We are well-equipped to handle the second two right here, but the first two might require some help from other groups. In particular, I would say it's a mistake to think that mod_perl specifically needs PR. There is no important difference between promoting mod_perl and promoting Perl in general. That's why I think this sort of thing should be pursued through The Perl Foundation, rather than as some sort of separate splinter group. yes and not you know, lot of leader says perl (in cgi of course, but they dont known mod perl) is so slow. so they use php or java or ... says mod_perl is really fast (i make a joke in my company, i said i have put off my atlhon 1 GHZ and get an xeon precessor, all saids 'whaow', in fact i just use mod_perl in the same computer) geve a complete idiot installation and sample application demonstration (maybe an rpm in /usr/local/httpd_modperl on port 8080 ... like tomcat's sample) and after you could says, it perl you can learn/use perl for your script, you system and you web, you xml application, ... i dont understand why the apache fondation dont talk more about perl (whitch is faster) but always of java/xml. it's just my point of view. Arnaud. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Perrin Harkins wrote: On Tue, 2004-06-08 at 10:55, Frank Wiles wrote: I agree mod_perl needs more PR. I think we've got a great community of people to help on the mailing list, tons of great documentation, but lack in several areas: 1) PR announcements in general (When is the last time you saw mod_perl in the press?) 2) Online and magazine articles about mod_perl 3) HOWTOs on specific subjects 4) Small application examples with developer commentary. These are really two different things. The first two are more about getting the word out while the second two are about helping people with practical coding issues. We are well-equipped to handle the second two right here, but the first two might require some help from other groups. In particular, I would say it's a mistake to think that mod_perl specifically needs PR. There is no important difference between promoting mod_perl and promoting Perl in general. That's why I think this sort of thing should be pursued through The Perl Foundation, rather than as some sort of separate splinter group. I tend to partially disagree here, when you talk about web technologies, one needs to choose between mod_perl, FastCGI, SpeedyCGI, mod_cgi, mod_php, mod_python, etc. So promoting mod_perl is a bit different than promoting Perl. Besides by promoting mod_perl you promote Perl - it's a two-edges sword. Since many of us will be in Portland for OSCON, maybe we should get together in person to discuss mod_perl PR in more detail? Yes, but maybe we should be more inclusive, like organizing a Perl PR BOF. That way we can keep the mod_perl BOF free for fun tech talk. From the [EMAIL PROTECTED] list it seems that one needs a killer app to promote Perl. while mod_perl is not an app, it can be a killer base driving killer Perl frameworks and Apps. So if mod_perl is successful as a technology choice, so much better for Perl. In any case, publishing mod_perl articles is something that could help a great deal. Once mp2.0 is released, I may start 2.0 series of articles on perl.com, similar to the mp1 series http://www.perl.com/pub/au/Stas_Bekman, which were republished on quite a few other sites (some of them linked here: http://stason.org/works/mod_perl.html). But we really need to get other folks write mod_perl and mod_perl apps articles. There are quite a few online zines (including perl.com) that have a very low barrier for article submissions. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Arnaud Blancher wrote: [...] i dont understand why the apache fondation dont talk more about perl (whitch is faster) but always of java/xml. Because someone needs to do the talk. Java XML developers have a pretty big development team, so they have resources/tuits to do that kind of things. The mod_perl dev team is so much smaller and hardly manages to do the development and support, and there are no tuits remaining for PR. That's why it'd be great if someone who is good at PR could step up and make things happen. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Stas == Stas Bekman [EMAIL PROTECTED] writes: Stas Because someone needs to do the talk. Java XML developers have a Stas pretty big development team, so they have resources/tuits to do that Stas kind of things. The mod_perl dev team is so much smaller and hardly Stas manages to do the development and support, and there are no tuits Stas remaining for PR. That's why it'd be great if someone who is good at Stas PR could step up and make things happen. I was surprised when of all 12 things I submitted for OSCON, one of the two accepted was my dinky little mod_perl talk. And it's not even in the Perl track, but in the Apache track. I'll do everything I can to continue to beat the drum about mod_perl. I've been reading this thread with interest, but if anyone wants to ensure that I'll cover a particularly interesting point in my talk, please email me. -- 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! -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
On Tue, 2004-06-08 at 12:27, Arnaud Blancher wrote: i dont understand why the apache fondation dont talk more about perl (whitch is faster) but always of java/xml. Where do you see the Java/XML stuff getting talked about? I mostly see it in Java magazines or websites, which is to be expected: Struts has a huge impact on Java developers just like mod_perl has a huge impact on Perl developers. If people can keep track of a few places where they would like to see more Perl coverage, we could try to use some of the name recognition of Apache to get some press releases out there. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Perrin Harkins [EMAIL PROTECTED] wrote: On Tue, 2004-06-08 at 12:27, Arnaud Blancher wrote: i dont understand why the apache fondation dont talk more about perl (whitch is faster) but always of java/xml. If people can keep track of a few places where they would like to see more Perl coverage, we could try to use some of the name recognition of Apache to get some press releases out there. As some of the Perl/Apache/XML projects mature, we could look at bringing them under the Apache umbrella as has been done with the Java/XML stuff -- thinking of SAWA and some of the stuff I'm working on in particular which have an opportunity to leap-frog some of the Java/XML stuff if we play it right. It would give it some weight for manager-types that think glossies make the technologies work. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Perrin Harkins wrote: On Tue, 2004-06-08 at 10:55, Frank Wiles wrote: I agree mod_perl needs more PR. I think we've got a great community of people to help on the mailing list, tons of great documentation, but lack in several areas: 1) PR announcements in general (When is the last time you saw mod_perl in the press?) 2) Online and magazine articles about mod_perl 3) HOWTOs on specific subjects 4) Small application examples with developer commentary. These are really two different things. The first two are more about getting the word out while the second two are about helping people with practical coding issues. We are well-equipped to handle the second two right here, but the first two might require some help from other groups. In particular, I would say it's a mistake to think that mod_perl specifically needs PR. There is no important difference between promoting mod_perl and promoting Perl in general. That's why I think this sort of thing should be pursued through The Perl Foundation, rather than as some sort of separate splinter group. I strongly disagree. One example about my own experience: I'm using perl for cgi scripts since 1996 and I very much love perl. I'm not a professional, and my daytime job (which is much more than daytime) has until now nothing to do with programming. Somewhere beginning of 2003, I started planning a new project, and was hesitating in what to write it. Just plain perl-cgi was much to slow. I looked at php. Why ? Because you hear about it, and see it everywhere (= PR !). It's only after a while I remembered having read something about mod_perl ... Then I started reading on perl.apache.org. My experience and opinion on documentation follows below. In my opinion mod_perl definitly needs a lot of extra PR. And as Stas more or less said in the meanwhile by promoting mod_perl your promote Perl, and you can even try to get the opposite when promoting Perl, get attention on mod_perl. All people out there that write web-applications get much to much publicity (as everyone does). So, it's very simple, they will start using the tools they've seen the most and/or heart the most about. And a lot of them don't want to change tools, because that again brings work and time, which they don't have or don't want to spent. In other words, the more you can promote it, the better. The more people read about it, the more people speak about it, the better. And I don't see any problem in co-promoting mp with Perl and vice versa. Both worlds will benefit of it in the long run. Then about the documentation: When I started reading on perl.apache.org, I didn't want to convert existing cgi scripts, but wanted to rewrite something completely from scratch. It would have been easier first to experiment with converting some existing scripts. But as many people I had (and still have) an enormous lack of time, and didn't want to waste time on things I would not use. I also noticed very quickly that there were important differences between mod_perl 1 2, so again, I didn't want to waste time on mod_perl 1, and started directly with mod_perl 2. For me, speed and usability always come on the first place, so I directly started with writing my own handlers using the modperl handler type. With this background, I found the documentation on mod_perl 2 difficult for a new user. I know most of the problems I encountered are more or less my own fault because I didn't want to spend time reading the docs of mod_perl 1. But I'm sure there are a lot of people out there with the same problem. And I must admit at some point I was thinking about giving up and re-starting with php. I've searched the internet on specific mp2 docs, and found some pdf's and slides from Stas. I also bought Practical mod_perl but was a bit dissappointed that there were only 2 chapters specific about mp2. In my opinion, it would be a good idea to think about reorganising the online documentation structure. Especially, to make it easier for new users who want to give it a try. And if they want "to give it a try", it's important they succeed quickly in this try, or they give up, and give a try to another tool. Again, the more people that use mp, the more people that will be convinced about mp, and then they will talk about it. I also find it a very interesting option when people can give comments within the documentation on a per subject basis (like you can do at http://www.php.net/manual/en/function.usort.php and at http://dev.mysql.com/doc/mysql/en/JOIN.html). Maybe another idea (a lot of small things can sometimes make big differences, and it's all about the big difference): If I'm correct there are no specific mod_perl logo's available. Apache, mysql, php, and others: they all have that, and you regurarly see them on sites. Maybe this is also an option to think about. None of my reactions here are meant as critics (also not on the documentation Stas), it's only meant to possibly
Re: mod_perl presence at OSCON (and other CONs) is at danger
On Tue, 2004-06-08 at 12:37, Stas Bekman wrote: In particular, I would say it's a mistake to think that mod_perl specifically needs PR. There is no important difference between promoting mod_perl and promoting Perl in general. That's why I think this sort of thing should be pursued through The Perl Foundation, rather than as some sort of separate splinter group. I tend to partially disagree here, when you talk about web technologies, one needs to choose between mod_perl, FastCGI, SpeedyCGI, mod_cgi, mod_php, mod_python, etc. So promoting mod_perl is a bit different than promoting Perl. Besides by promoting mod_perl you promote Perl - it's a two-edges sword. Well, everyone seems to disagree with me about this. Before I give up on this point, let me say a few things: 1) Drawing distinctions between mod_perl, FastCGI, and SpeedyCGI is mostly pointless and helps nobody. Yes, you can do additional things with mod_perl, principally apache 2 filters and separate access handlers, but most people don't care about this. The important thing is that you can run large Perl applications very fast. The majority of web apps that people run on one of these environments could be moved to any of the others with minimal changes. 2) Helping people understand that mod_perl is hugely faster than CGI is important. I would like to work on a good approach for this. I have some ideas, but they will have to wait until after YAPC. 3) I believe that mod_php, mod_python, etc. principally compete with mod_perl based on language preference. Promotion of Perl covers that, and gives us vastly more resources to draw on. I also think that separating the notions of Perl from CGI is a good thing, but separating mod_perl from Perl is not. There are enough misconceptions out there already about what mod_perl is without more of them coming from us. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Stefan Loones [EMAIL PROTECTED] 06/08 2:50 pm I also find it a very interesting option when people can give comments within the documentation on a per subject basis (like you can do at http://www.php.net/manual/en/function.usort.php and at http://dev.mysql.com/doc/mysql/en/JOIN.html). +1 for comments within the documentation. I would be willing to donate my time to make this happen. --Ian -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Good points. Also, I think we need some work on the FUTURE of mod_perl. New users look for tools which will let them keep on the bandwagon for the next 5 years. This is XML. For those php, java or .NET users, if one day we tell people that all those interesting tools on Apache/Java projects can be equally supported by mod_perl at background but just faster and more stable (which is true); a lot of people will shift. BTW, I programmed a mod_perl based BBS system for a site. It got almost 200,000 (!) unique IP hits every day with the dual set-up (plain apache + mod_perl). This might be an example where others such as php and java servlet can't compete. Right? Pod Merl ---BeginMessage--- Perrin Harkins wrote: On Tue, 2004-06-08 at 10:55, Frank Wiles wrote: I agree mod_perl needs more PR. I think we've got a great community of people to help on the mailing list, tons of great documentation, but lack in several areas: 1) PR announcements in general (When is the last time you saw mod_perl in the press?) 2) Online and magazine articles about mod_perl 3) HOWTOs on specific subjects 4) Small application examples with developer commentary. These are really two different things. The first two are more about getting the word out while the second two are about helping people with practical coding issues. We are well-equipped to handle the second two right here, but the first two might require some help from other groups. In particular, I would say it's a mistake to think that mod_perl specifically needs PR. There is no important difference between promoting mod_perl and promoting Perl in general. That's why I think this sort of thing should be pursued through The Perl Foundation, rather than as some sort of separate splinter group. I strongly disagree. One example about my own experience: I'm using perl for cgi scripts since 1996 and I very much love perl. I'm not a professional, and my daytime job (which is much more than daytime) has until now nothing to do with programming. Somewhere beginning of 2003, I started planning a new project, and was hesitating in what to write it. Just plain perl-cgi was much to slow. I looked at php. Why ? Because you hear about it, and see it everywhere (= PR !). It's only after a while I remembered having read something about mod_perl ... Then I started reading on perl.apache.org. My experience and opinion on documentation follows below. In my opinion mod_perl definitly needs a lot of extra PR. And as Stas more or less said in the meanwhile by promoting mod_perl your promote Perl, and you can even try to get the opposite when promoting Perl, get attention on mod_perl. All people out there that write web-applications get much to much publicity (as everyone does). So, it's very simple, they will start using the tools they've seen the most and/or heart the most about. And a lot of them don't want to change tools, because that again brings work and time, which they don't have or don't want to spent. In other words, the more you can promote it, the better. The more people read about it, the more people speak about it, the better. And I don't see any problem in co-promoting mp with Perl and vice versa. Both worlds will benefit of it in the long run. Then about the documentation: When I started reading on perl.apache.org, I didn't want to convert existing cgi scripts, but wanted to rewrite something completely from scratch. It would have been easier first to experiment with converting some existing scripts. But as many people I had (and still have) an enormous lack of time, and didn't want to waste time on things I would not use. I also noticed very quickly that there were important differences between mod_perl 1 2, so again, I didn't want to waste time on mod_perl 1, and started directly with mod_perl 2. For me, speed and usability always come on the first place, so I directly started with writing my own handlers using the modperl handler type. With this background, I found the documentation on mod_perl 2 difficult for a new user. I know most of the problems I encountered are more or less my own fault because I didn't want to spend time reading the docs of mod_perl 1. But I'm sure there are a lot of people out there with the same problem. And I must admit at some point I was thinking about giving up and re-starting with php. I've searched the internet on specific mp2 docs, and found some pdf's and slides from Stas. I also bought Practical mod_perl but was a bit dissappointed that there were only 2 chapters specific about mp2. In my opinion, it would be a good idea to think about reorganising the online documentation structure. Especially, to make it easier for new users who want to give it a try. And if they want "to give it a try", it's important they succeed quickly in this try, or they give up, and give a try to another tool. Again, the more people that use mp, the more people that will be convinced about
Re: mod_perl presence at OSCON (and other CONs) is at danger
On Tue, 2004-06-08 at 15:50, Stefan Loones wrote: I looked at php. Why ? Because you hear about it, and see it everywhere (= PR !). Where? Where do you see it that you are not seeing Perl represented? Keep track, and then we'll have some targets to pursue for placing articles. In my opinion mod_perl definitly needs a lot of extra PR. My intention was that mod_perl would be talked about in the larger context of Perl, as the standard way to build web apps. There could be an ad promoting web development with mod_perl, one promoting Bioinformatics use, one promoting use in financial companies, one for sysadmin and DBA use, etc. If you notice, no one talks about mod_php. Instead they talk about PHP. That's because mod_php is just some glue code that lets you run PHP in apache, just like mod_perl lets you run Perl. I already run into people who know Perl and think that mod_perl is some other language they would have to learn, and that's not good. With this background, I found the documentation on mod_perl 2 difficult for a new user. As you say, this is partly because you chose to start with Apache/mod_perl 2. The documentation for mod_perl 1 is more approachable for newbies at the moment, and it is where I would point any new person wanting to learn mod_perl. Maybe another idea (a lot of small things can sometimes make big differences, and it's all about the big difference): If I'm correct there are no specific mod_perl logo's available. They're in the About mod_perl section: http://perl.apache.org/about/link/linktous.html - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
On Tue, 08 Jun 2004 17:43:23 -0400 Perrin Harkins [EMAIL PROTECTED] wrote: On Tue, 2004-06-08 at 15:50, Stefan Loones wrote: I looked at php. Why ? Because you hear about it, and see it everywhere (= PR !). Where? Where do you see it that you are not seeing Perl represented? Keep track, and then we'll have some targets to pursue for placing articles. I'd be happy to gather these up for everyone and bring them all to the BOF. If you find examples of where other tech is being discussed, but not mod_perl feel free to E-mail it to me directly and I'll correlate it all. You can obviously omit websites/magazines entirely devoted to a particular technology. I don't think we'll have much luck getting much perl/mod_perl PR on www.php.net or in a Java magazine. ;) In my opinion mod_perl definitly needs a lot of extra PR. My intention was that mod_perl would be talked about in the larger context of Perl, as the standard way to build web apps. There could be an ad promoting web development with mod_perl, one promoting Bioinformatics use, one promoting use in financial companies, one for sysadmin and DBA use, etc. If you notice, no one talks about mod_php. Instead they talk about PHP. That's because mod_php is just some glue code that lets you run PHP in apache, just like mod_perl lets you run Perl. I already run into people who know Perl and think that mod_perl is some other language they would have to learn, and that's not good. I agree that we should work to make sure mod_perl is accurately portrayed and do our best to avoid misinterpretations that mod_perl is a separate language, etc. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org - -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Fw: Re: mod_perl presence at OSCON (and other CONs) is at danger
Accidentally only sent this to Perrin. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org - Begin forwarded message: Date: Tue, 8 Jun 2004 16:53:48 -0500 From: Frank Wiles [EMAIL PROTECTED] To: Perrin Harkins [EMAIL PROTECTED] Subject: Re: mod_perl presence at OSCON (and other CONs) is at danger On Tue, 08 Jun 2004 17:43:23 -0400 Perrin Harkins [EMAIL PROTECTED] wrote: On Tue, 2004-06-08 at 15:50, Stefan Loones wrote: I looked at php. Why ? Because you hear about it, and see it everywhere (= PR !). Where? Where do you see it that you are not seeing Perl represented? Keep track, and then we'll have some targets to pursue for placing articles. I'd be happy to gather these up for everyone and bring them all to the BOF. If you find examples of where other tech is being discussed, but not mod_perl feel free to E-mail it to me directly and I'll correlate it all. You can obviously omit websites/magazines entirely devoted to a particular technology. I don't think we'll have much luck getting much perl/mod_perl PR on www.php.net or in a Java magazine. ;) In my opinion mod_perl definitly needs a lot of extra PR. My intention was that mod_perl would be talked about in the larger context of Perl, as the standard way to build web apps. There could be an ad promoting web development with mod_perl, one promoting Bioinformatics use, one promoting use in financial companies, one for sysadmin and DBA use, etc. If you notice, no one talks about mod_php. Instead they talk about PHP. That's because mod_php is just some glue code that lets you run PHP in apache, just like mod_perl lets you run Perl. I already run into people who know Perl and think that mod_perl is some other language they would have to learn, and that's not good. I agree that we should work to make sure mod_perl is accurately portrayed and do our best to avoid misinterpretations that mod_perl is a separate language, etc. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org - - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org - -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
On Tue, Jun 08, 2004 at 05:43:23PM -0400, Perrin Harkins wrote: With this background, I found the documentation on mod_perl 2 difficult for a new user. As you say, this is partly because you chose to start with Apache/mod_perl 2. The documentation for mod_perl 1 is more approachable for newbies at the moment, and it is where I would point any new person wanting to learn mod_perl. Still, and just to add my 2 cts, I see the 1.0 - 2.0 dilemma as one of the large drawbacks at the moment. Almost all new distros are equipped with Apache 2 and thus MP2. But as you say: the documen- tation is not that good yet, nor are the books. And (big problem!) not all modules are usable under MP2. I recently tried to migrate to MP2 (from MP1), but stopped that performance when it looked like it would cost too much time without a certain chance to success. So the choice is for MP1 then. But this means installing Apache 1.3, not benefitting from new features and the guarantee that one is using ancient technique. Now please, don't read this as MP-bashing, but if you want to attrackt new people, this is certainly worth some attention. I for one would love to visit your talks, but unfortunately it is too costly to jump the ocean (or even travel far into Europe). Will try to catch up with your slides though. --Frank -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
--- [EMAIL PROTECTED] wrote: BTW, I programmed a mod_perl based BBS system for a site. It got almost 200,000 (!) unique IP hits every day with the dual set-up (plain apache + mod_perl). This might be an example where others such as php and java servlet can't compete. Right? Not in my opinion. Both PHP and mod_perl are mature enough that performance differences are more likely to be due to the design of an application rather than the language it is written in. I've written applications in PHP that currently handle over 10 million requests a day (the environment consists of four servers), and there's still room to grow. With a compiler cache and an intelligent design (including data storage), PHP can handle just about anything (look at Yahoo). I personally think mod_perl's strengths are in its rich feature set. Only after watching a few of Geoff's talks (and one of Stas's) did I realize exactly what PHP developers are missing. They speak about things like ties, closures, and globs. Plus, PHP is limited to the content generation phase, so mod_perl has a pretty big advantage there. Geoff describes mod_perl as the Apache API in Perl. While this is probably obvious to all of you, it's not something I realized on my own. Of course, CPAN is also a pretty big trump card. :-) Chris -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
--- Perrin Harkins [EMAIL PROTECTED] wrote: If you notice, no one talks about mod_php. Instead they talk about PHP. Well, there are a few reasons for that, and none of them have to do with PR really. First, PHP was not created as a general-purpose scripting language. There is now a command-line interpreter (I'm sure the thought of shell scripts written in PHP make some of you shudder), but it wasn't there until recently. In fact, referencing this is very clumbsy, and most people call it the PHP CLI. So, it gives us something like this: Perl:mod_perl::PHP CLI:PHP Another reason for the naming habits is that PHP runs on more Web servers than Apache, and only the Apache SAPI is called mod_php. And, because mod_php doesn't implement the full Apache API (another rarely-used and experimental SAPI called apache_hooks does), there isn't anything significant to distinguish mod_php from any other the other SAPIs, so you'll almost never see it referenced in conversation. Anyway, there's a PHP guy's perspective. Chris -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Fw: Re: mod_perl presence at OSCON (and other CONs) is at danger
It depends how to define programming language. It seems more properly a comparison between php and Mason because mod_perl itself is the Apache API in Perl language. For newbies, this API is indeed hard to program with. My 2 cents is that mod_perl lacks an established application server/tookits so for a serious web application, programmers have to rely mostly on the original API to get the full benifit. While there sevearl great application tools like mason, ePerl, TT etc., yet, none of them is as established as php at the moment (in the sense: easy to write, support, coder community, code samples etc.) Occasionally, I thought we might start up with a new application server that has features like these: 1) MVC model; 2) XHTML templates; 3) backend programming based on XML (e.g. parsing parameters like STRUTS), so other java, .NET applications can be translated as easy as possible; 4) some special cares on the places where mod_perl may be weak (such as memory usuage), so there might be a few special C modules for things like system-wide authentication. and so on. Well, my random thoughts Pod Merl Date: Tue, 8 Jun 2004 16:53:48 -0500 From: Frank Wiles [EMAIL PROTECTED] To: Perrin Harkins [EMAIL PROTECTED] Subject: Re: mod_perl presence at OSCON (and other CONs) is at danger . In my opinion mod_perl definitly needs a lot of extra PR. My intention was that mod_perl would be talked about in the larger context of Perl, as the standard way to build web apps. There could be an ad promoting web development with mod_perl, one promoting Bioinformatics use, one promoting use in financial companies, one for sysadmin and DBA use, etc. If you notice, no one talks about mod_php. Instead they talk about PHP. That's because mod_php is just some glue code that lets you run PHP in apache, just like mod_perl lets you run Perl. I already run into people who know Perl and think that mod_perl is some other language they would have to learn, and that's not good. I agree that we should work to make sure mod_perl is accurately portrayed and do our best to avoid misinterpretations that mod_perl is a separate language, etc. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org - - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org - -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
--- Frank Maas [EMAIL PROTECTED] wrote: So the choice is for MP1 then. But this means installing Apache 1.3, not benefitting from new features and the guarantee that one is using ancient technique. Well, for what it's worth, the situation is much the same in the PHP camp. We still recommend using Apache 1.3 for any production use of PHP. Those who insist on using Apache 2 have to use the pre-fork MPM. While PHP core is thread-safe, many of the extensions (even bundled ones) are not. So, I don't see the MP1/MP2 transition as a big problem for mod_perl. Chris -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
On Tue, 8 Jun 2004, Chris Shiflett wrote: Date: Tue, 8 Jun 2004 15:38:50 -0700 (PDT) From: Chris Shiflett [EMAIL PROTECTED] To: [EMAIL PROTECTED], Modperl List [EMAIL PROTECTED] Subject: Re: mod_perl presence at OSCON (and other CONs) is at danger --- [EMAIL PROTECTED] wrote: BTW, I programmed a mod_perl based BBS system for a site. It got almost 200,000 (!) unique IP hits every day with the dual set-up (plain apache + mod_perl). This might be an example where others such as php and java servlet can't compete. Right? Not in my opinion. Both PHP and mod_perl are mature enough that performance differences are more likely to be due to the design of an application rather than the language it is written in. I've written applications in PHP that currently handle over 10 million requests a day (the environment consists of four servers), and there's still room to grow. With a compiler cache and an intelligent design (including data storage), PHP can handle just about anything (look at Yahoo). I personally think mod_perl's strengths are in its rich feature set. Only after watching a few of Geoff's talks (and one of Stas's) did I realize exactly what PHP developers are missing. They speak about things like ties, closures, and globs. Plus, PHP is limited to the content generation phase, so mod_perl has a pretty big advantage there. Geoff describes mod_perl as the Apache API in Perl. While this is probably obvious to all of you, it's not something I realized on my own. This sounds like a perfect example of mod_perl lacking PR. MP had an almost full set of features from Apache from day 1. And it was easy to add one when you need it (Doug did this for me, for example). Had you known about mod_perl first, would you have gone to the PHP camp? PHP has been patched again and again stealing MP features. I don't have a deep knowledge of PHP, but I have serious doubt about it, from my experience running one server using it. I don't intend to start a flame war here, but just want to share my own experience. And the point is that there is need for some more PR for mod_perl. When you go to httpd.apache.org, you can hardly find mod_perl mentioned. Even mod_python is there. :-( This is not good for mod_perl. Any idea about the share of mod_perl in the server market recently? Regards, Jie -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
--- [EMAIL PROTECTED] wrote: BTW, I programmed a mod_perl based BBS system for a site. It got almost 200,000 (!) unique IP hits every day with the dual set-up (plain apache + mod_perl). This might be an example where others such as php and java servlet can't compete. Right? Not in my opinion. Both PHP and mod_perl are mature enough that performance differences are more likely to be due to the design of an application rather than the language it is written in. agree, that the design is very important. I've written applications in PHP that currently handle over 10 million requests a day (the environment consists of four servers), and there's still room to grow. With a compiler cache and an intelligent design (including data storage), PHP can handle just about anything (look at Yahoo). This is great. I actually did not have data on hand as how many hits the php can handle. This is amazing. For your reference, mine is 1 server :-) (but dual plain+mod_perl setup), and pretty a good-runner in Alexa. I personally think mod_perl's strengths are in its rich feature set. Only after watching a few of Geoff's talks (and one of Stas's) did I realize exactly what PHP developers are missing. They speak about things like ties, closures, and globs. Plus, PHP is limited to the content generation phase, so mod_perl has a pretty big advantage there. Geoff describes mod_perl as the Apache API in Perl. While this is probably obvious to all of you, it's not something I realized on my own. Of course, CPAN is also a pretty big trump card. :-) Chris As in my other post, it seems more proper a comparison between an mod_perl based application server and php. Theoretically, mod_perl can make one that have all the advantages in php (fast to run, and easy to program), XML (universal data parsing), and MVC (seperating code, data, and presentation) Pod Merl -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
On Tue, 2004-06-08 at 18:47, Chris Shiflett wrote: Another reason for the naming habits is that PHP runs on more Web servers than Apache, and only the Apache SAPI is called mod_php. This is exactly the same situation as Perl. Perl has SAPI support on IIS through PerlEx, lots more through FastCGI, and runs persistently with any server that supports CGI via PersistentPerl. (AFAIK, PHP has no equivalent for that.) This is part of why I think singling out mod_perl, as opposed to talking about Perl's speed and SAPI support in general and giving mod_perl as an example, is a questionable tactic. If you include all of the above groups, you have a lot more friends (ActiveState) and reference accounts (Amazon.com). I personally think mod_perl's strengths are in its rich feature set. Only after watching a few of Geoff's talks (and one of Stas's) did I realize exactly what PHP developers are missing. They speak about things like ties, closures, and globs. Those are all features of Perl, not mod_perl. I would have thought PHP developers would be more anxious to get features like separate comparison operators for strings and numbers or more than one name space for functions! :) - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Fw: Re: mod_perl presence at OSCON (and other CONs) is at danger
[EMAIL PROTECTED] wrote: Occasionally, I thought we might start up with a new application server that has features like these: 1) MVC model; 2) XHTML templates; 3) backend programming based on XML (e.g. parsing parameters like STRUTS), so other java, .NET applications can be translated as easy as possible; 4) some special cares on the places where mod_perl may be weak (such as memory usuage), so there might be a few special C modules for things like system-wide authentication. and so on. While we're on the topic of PR, I'll go ahead and insert a shameless plug for a project I've been working on :) I'm hoping to get another release out before OSCon (one that actually installs :/), but Gestinanna is a project I've been working on for a year or two now that has the following features: o Separation of Model, View, and Controller Model is supplied in the form of taglibs that extend the language of the Controller that determines which of the Views get used to present data to the customer. o The Controller is written as (what I'm calling) an eXtensible StateMachine (XSM for short, using a SAX XML-Perl compiler) which is a collection of XML namespaces and schemas that can be used to define state machines and add scripting that gets triggered when it changes state (and offering basic continuations in the process, though I'm thinking hard on how to extend it to make it even more useful). This language is declarative / descriptive (similar to XSLT) instead of the usual prescriptive form that we're used to in Perl and PHP. o Views are written in a docbook-derived schema that allows easier transformation to various devices (screen, handheld, etc.) with extensions to handle forms. The views are processed by Template Toolkit to allow some simple scripting for managing data insertion into the view. (This was a decision based on who was going to be managing the views where I work.) o Uses AxKit to manage the transformation from XML to HTML or other format. o Abstraction of data sources so applications can be written in a generic fashion as to both model and data source. o Extremely flexible security / ACL language using XPath-like specifications for sets of objects o full application inheritance of states as well as views, both IS-A and HAS-A style o support for embedding multiple application views within a page and for themes o command-line management tool for managing installation of applications (from .tar.gz packages) as well as RDBMS schema management (with inheritable schemas from packages). o revision control system for all scripts, views, etc., managed within the application framework. Uses the idea of tag paths so not all the members of a tag need to be tagged - just the ones that are different from the previous tag. In addition, I have been able to use the scripting to define workflows using the Workflow module recently submitted to CPAN. This is still needing some testing and integration work though. Also working on starting DAV support with the recent publishing of a perl module that handles DAV requests. I'm in the process of revamping the testing code as well as cleaning up a few other odds and ends. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
--- Perrin Harkins [EMAIL PROTECTED] wrote: This is exactly the same situation as Perl. Perl has SAPI support on IIS through PerlEx, lots more through FastCGI, and runs persistently with any server that supports CGI via PersistentPerl. (AFAIK, PHP has no equivalent for that.) That's correct, although I think a few people are interested in implementing some sort of persistent server like that. This is part of why I think singling out mod_perl, as opposed to talking about Perl's speed and SAPI support in general and giving mod_perl as an example, is a questionable tactic. Yes, I now understand your earlier point, and I agree. I didn't realize that Perl had SAPI support outside of Apache (well, I never gave it much thought either). Shows what I know. I would have thought PHP developers would be more anxious to get features like separate comparison operators for strings and numbers or more than one name space for functions! :) Namespaces would be a dream come true for me, personally. That's probably my biggest complaint about PHP (and one of the most valid complaints made by those who don't grok PHP). Chris -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
--- Geoffrey Young [EMAIL PROTECTED] wrote: while I realize I'm in the minority with this view (and perrin and I have had this discussion/friendly disagreement before :) what _I_ like about mod_perl cannot be satisfied by anything other than mod_perl - I like the Apache API... Good point, and one I had forgotten. The other SAPIs Perrin mentioned would be more inline with what PHP offers, I assume, whereas mod_perl offers much more. I think mod_perl more than that, and that is why I feel beaten down when nobody seems to care about mod_perl for what it really is, or people say you can just swap it out for FastCGI or something and things move on. that's when I feel like I'm wasting my time. Well, surely there are plenty of people fully utilizing mod_perl for all it's worth. Are there things you can speak/write about more to illustrate the benefit of the Apache API? Input/output filters seem like one such thing, and surely there are others. I think most people (e.g., those who don't subscribe to mailing lists such as this) aren't so interested in academic debates but more in the practical implications of things. I'm sure you can appeal to these types of people with the right angle. After all, you made me a believer, and I'm an outsider. :-) Chris -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Chris == Chris Shiflett [EMAIL PROTECTED] writes: Chris Well, surely there are plenty of people fully utilizing mod_perl for all Chris it's worth. Are there things you can speak/write about more to illustrate Chris the benefit of the Apache API? Input/output filters seem like one such Chris thing, and surely there are others. I've personally used trans, postreadrequest, log, mime, and auth, as well as the normal content handler. Each type of the 14 handler slots provides a specific contribution to the response given by a request. -- 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! -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Geoffrey Young [EMAIL PROTECTED] wrote: .. while I realize I'm in the minority with this view (and perrin and I have had this discussion/friendly disagreement before :) what _I_ like about mod_perl cannot be satisfied by anything other than mod_perl - I like the Apache API, and I would prefer to use it in conjunction with Perl rather than mess around with C (or even something like apache_hooks, since I don't know php :) for those that share a love for this particular aspect of mod_perl and have a desire to see it prosper, nothing else will really do. minority of the loving group of API? probably not :-) The only place where the C API overrides the Perl API in mp1, IMHO, is for the configuration process. To do somehow a complicated configuration in Perl seems even more difficult than in C. Well, maybe I should sit down and read those chapters in the 3 books again :-) -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
On Tue, 8 Jun 2004, Geoffrey Young wrote: well, I think it really depends on what you want to accomplish. all the above really seems like just a perl versus php (or $web_language) debate: both run on a number of different server platforms, have strong followings, and are proven scalable and enterprise (sorry for throwing out that term, but you get the idea :). in the end, arguments like the above are very, very important ones for us as perl programmers, but I don't think they help mod_perl prosper as a technology, which is what I'm interested in :) while I realize I'm in the minority with this view (and perrin and I have had this discussion/friendly disagreement before :) what _I_ like about mod_perl cannot be satisfied by anything other than mod_perl - I like the Apache API, and I would prefer to use it in conjunction with Perl rather than mess around with C (or even something like apache_hooks, since I don't know php :) for those that share a love for this particular aspect of mod_perl and have a desire to see it prosper, nothing else will really do. I agree with Geoff on both points above, but in my experience the things that are obvious and important to us as mod_perl programmers are not necessarily the primary considerations for choosing a platform when a project is ramping up (even if they should be). Designs are not always well thought out, and future development of projects can't always be predicted, so sometimes it might only be in hindsight that you realize that you have a need that could have easily been satisfied by the power/flexibility of mod_perl but not necessarily by the platform you chose (assuming you didn't choose mod_perl in the first place...). What I have seen is people initially choosing a platform because it quickly meets the needs of a prototype or proof of concept, and then that chosen platform ends up being what's released in production. When you want to get a proof of concept up and running quickly, you might tend to look for systems where it's quick and easy to implement common infrastructure tasks like: managing user sessions, managing database connections, handling config files, and logging. This lets you concentrate on your application code, which is the interesting part. For example, I've spoken with people who said they chose PHP or ASP for the initial implementation of a project specifically because they thought it looked like it would be easy to handle sessions and/or do database coding, and they assumed it would be sufficient for the rest of the application stuff they needed to do. We mod_perl people know there are (many) straightforward solutions for those kind of infrastructure things, e.g. Apache::Session::*, Apache::DBI, Config::IniFiles, and Log4Perl, respectively. But I don't think it's obvious at all to newbies or outsiders that those kind of things are available or easily implemented. So getting back to an idea that appeared early in the thread, it would probably be good to have something like a centralized, well-documented toolkit of code/modules/patterns (not sure the best form that would take) that could be quickly hooked together into a skeleton application. I know all the pieces are out there, maybe it's just a matter of figuring out the best presentation... Larry -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Chris : I personally think mod_perl's strengths are in its rich feature set. Only after watching a few of Geoff's talks (and one of Stas's) did I realize exactly what PHP developers are missing. They speak about things like ties, closures, and globs. Plus, PHP is limited to the content generation phase, so mod_perl has a pretty big advantage there. Geoff describes mod_perl as the Apache API in Perl. While this is probably obvious to all of you, it's not something I realized on my own. we all know there are so many technologies for web programing, ASP,PHP,Python,Java etc. what makes one choose mod_perl over others? why learn/use mod_perl, why mod_perl instead of php etc. a section about these on perl.apache.org would be good intro to people who curious about mod_perl. I think php is used more often because it does most of the small to medium projects just fine and it does easier. at least that's what i heard ( i dont have any expereience on php ). I also likes Stef's idea about adding user comments for doc. hope it can happen. hmm, does mod_perl still have problem running for virtual hosts? people choose php over cgi for obvious reason. __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl presence at OSCON (and other CONs) is at danger
Stas Bekman wrote: It so appears that in the last few years we get less and less mod_perl talks and tutorials at the big (non-YAPC) conferences. And that's a bad trend. It certainly affects the number of mod_perl job offers, since those who decide which technology to choose for their next project go to those big conferences and chances are very high that they will pick the technology that had a dominating presense in terms of tutorials and presentations. I have seen both you and Geoff give talks at various conferences, and have always learned something new. I would recommend talks and tutorials by either of you to anyone interested in learning more about mod_perl. I don't see the same gloomy story in the conferences this year though. It seems likely to me that nearly every talk about web-related uses of Perl will talk about mod_perl in some way. Even Vivek's talk which has PersistentPerl in the title will probably mention whether or not the techniques are all equally applicable to mod_perl. mod_perl is no longer a new tchnology that people need lots of help to understand; it is now the accepted standard for building any serious web application in Perl. The result is that there is less talk about mod_perl itself and more about what people are doing with it. This is partly due to the work that you and others have done over the last few years: good books and on-line documentation are now available to teach people mod_perl, and even survey books like Perl Cookbook cover it. These days, nearly every web-related job posted on jobs.perl.org asks for mod_perl experience. That's a good sign of success to me, and is a lot different from how things were a few years ago. Thanks to you and Geoff for your ongoing efforts in support of mod_perl and this community. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
