You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/06/05 00:09:49 UTC
mod_perl presence at OSCON (and other CONs) is at danger
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.
How can you change that? Go to the big (non-YAPC) conferences and especially
to mod_perl tutorials. Since conference organizers get a lion chunk of their
revenues (even if only to cut it even) from the tutorials, that's where the
battle is. The less tutorials on the mod_perl technology you have, the less
mod_perl presentations and overall presence will be, the less new mod_perl
jobs will be created.
This year mod_perl's presense at OSCon really sucks. We have two tutorials
which are under a question that will happen at all and just one mod_perl
presentation. Plus a few more related presentations of technologies riding
mod_perl. Just a few years ago, we had about 25 tutorials and presentations.
If some of the mod_perl tutorials will be canceled this year, don't expect the
conference organisers giving them a second chance next year, which brings us
pretty close to zero presence. And that's a gloomy future if you ask me.
So if you want to change things, go to your bosses and ask them to send you to
the tutorials. If they can't afford two, make it one and make that choice
Geoffrey Young's "Programming the Apache Lifecycle"
http://conferences.oreillynet.com/cs/os2004/view/e_sess/5082
Why Geoffrey's? It's because the stuff I'm going to teach you at my tutorial
is ready available in the online documentation and you can read it by
yourself. But not so for Geoff's unique material. And all those who have ever
heard Geoff presenting, will agree with me, that he is one of the best
speakers OSCon (and other conferences) ever had and most of us, speakers, need
to learn from Geoff. I'd go for Geoff's talk just for the great experience,
even though I know most of the material he presents. His tutorial will be
covering both mp1 and mp2 if you didn't know.
So if you enjoy your mod_perl job and want to continue so in the future, make
sure that you come to the mod_perl tutorials and presentations at OSCon and
other big conferences.
Here is the OSCon info.
http://conferences.oreillynet.com/os2004/
p.s. the deadline for tutorial cutoffs (at least 20 attendees) is June 21th.
So if you were planning to go to the tutorials, make sure you register (or add
the tutorials if you already did) before that date.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Posted by Frank Wiles <fr...@wiles.org>.
On Tue, 08 Jun 2004 09:03:01 -0700
Stas Bekman <st...@stason.org> wrote:
> Frank Wiles wrote:
> [...]
> > 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.
>
> Are you taking a lead on organizing that BOF, Frank? I suppose there
> should be two BOFs then - one dealing with mod_perl usage and the
> other with PR?
>
> Again, the URL for BOF submission is here:
> http://conferences.oreillynet.com/pub/w/29/bof.html
Will do! I'll setup two BOFs and post the date/times to the list
once they are setup and approved.
---------------------------------
Frank Wiles <fr...@wiles.org>
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
Posted by Stas Bekman <st...@stason.org>.
Frank Wiles wrote:
[...]
> 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.
Are you taking a lead on organizing that BOF, Frank? I suppose there should be
two BOFs then - one dealing with mod_perl usage and the other with PR?
Again, the URL for BOF submission is here:
http://conferences.oreillynet.com/pub/w/29/bof.html
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Posted by Thomas Klausner <do...@zsi.at>.
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-:+-$"-g&&print$_.$/}
--
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: docs
Posted by Chris <ch...@prather.org>.
On Wed, 09 Jun 2004 07:09:16 -0700, Stas Bekman wrote
> Chris wrote:
> > On Wed, 09 Jun 2004 06:01:12 -0700, Stas Bekman wrote
> >
> >>Chris Shiflett wrote:
> >>
> >>Alternatively, someone may want to start a wiki project where people
> >>can dump anythings they want, and then we can merge some of those
> >>notes back into the docs.
> >
> >
> > Right then, unless someone comes up with something better:
> >
> > http://dahut.pm.org/mp_wiki
> >
> > I've been wanting to give something back to you and Geoff for a while Stas.
> > Hopefully this will help where my non-existant time and energy cannot.
>
> Thanks Chris! Where do you want me to add links to it from
> perl.apache.org? Let's see if it takes off. I suppose it needs some
> guidelines on the front page?
I had no clue what to put in there, I simply copied across the install I did
for Orlando.pm and changed the title in the templates. Tonight when I get back
home I'll also copy across a TextFormatting page from one of the other
CGI::Wiki projects I run.
I was thinking something along the lines of an exgesis (Talmud??) for the
perl.apache.org/docs/, here we can expand upon ideas/topics in the main docs
and then formulate actual doc patches from that.
Finally please send me bug reports, the code is still a little flakey and some
of the features are on back-order. I just a second major move in the last year
and I'm just getting myself back to where I can hack out features in my spare
time.
--
Prather.org (powered by OpenWebmail, Perl, and Apache)
--
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: docs
Posted by Stas Bekman <st...@stason.org>.
Chris wrote:
> On Wed, 09 Jun 2004 06:01:12 -0700, Stas Bekman wrote
>
>>Chris Shiflett wrote:
>>
>>Alternatively, someone may want to start a wiki project where people
>>can dump anythings they want, and then we can merge some of those
>>notes back into the docs.
>
>
> Right then, unless someone comes up with something better:
>
> http://dahut.pm.org/mp_wiki
>
> I've been wanting to give something back to you and Geoff for a while Stas.
> Hopefully this will help where my non-existant time and energy cannot.
Thanks Chris! Where do you want me to add links to it from perl.apache.org?
Let's see if it takes off. I suppose it needs some guidelines on the front page?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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: docs
Posted by Chris <ch...@prather.org>.
On Wed, 09 Jun 2004 06:01:12 -0700, Stas Bekman wrote
> Chris Shiflett wrote:
>
> Alternatively, someone may want to start a wiki project where people
> can dump anythings they want, and then we can merge some of those
> notes back into the docs.
Right then, unless someone comes up with something better:
http://dahut.pm.org/mp_wiki
I've been wanting to give something back to you and Geoff for a while Stas.
Hopefully this will help where my non-existant time and energy cannot.
-Chris
--
Prather.org (powered by OpenWebmail, Perl, and Apache)
--
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: docs
Posted by Stas Bekman <st...@stason.org>.
Chris Shiflett wrote:
> --- Stas Bekman <st...@stason.org> wrote:
>
>>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.
>
>
> This is true, but I don't think it discounts the merit in having user
> comments. One of the best features of the PHP manual is the user comments,
> and it's helpful for those weird scenarios that maybe only a couple of
> developers encounter. It also encourages more people to contribute.
>
> While it would be nice to think that anyone with a contribution to make
> would submit a documentation patch, I think you'll find that giving people
> an easy form to add a comment results in much more feedback, and other
> developers who reference the manual seem to really appreciate some of this
> random insight.
>
> A good approach to take with user comments is actually to try to get rid
> of them (I know, it sounds contradictory). You basically want to delete
> the ones that aren't valid and integrate the valid ones into the
> documentation itself. Sometimes those who write the documentation may not
> have thought of something, and a good user comment can make documentation
> maintenance much easier.
>
> So, while user comments may not be the best idea, I don't think it is an
> idea that is completely without merit. Of course, as you suggest, ideas
> are cheap (mine included). Suggesting user comments would be much better
> bundled with some code. :-)
Sure, it's perfectly reasonable. But nothing prevents those users from posting
those comments to the list and then they will be integrated into the docs.
This kind of approach is useful for those rare cases, when a solution is not a
generic one. For most users it's much better to have less docs, to be more
digestible.
Alternatively, someone may want to start a wiki project where people can dump
anythings they want, and then we can merge some of those notes back into the
docs.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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: docs
Posted by Chris Shiflett <sh...@php.net>.
--- Stas Bekman <st...@stason.org> wrote:
> 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.
This is true, but I don't think it discounts the merit in having user
comments. One of the best features of the PHP manual is the user comments,
and it's helpful for those weird scenarios that maybe only a couple of
developers encounter. It also encourages more people to contribute.
While it would be nice to think that anyone with a contribution to make
would submit a documentation patch, I think you'll find that giving people
an easy form to add a comment results in much more feedback, and other
developers who reference the manual seem to really appreciate some of this
random insight.
A good approach to take with user comments is actually to try to get rid
of them (I know, it sounds contradictory). You basically want to delete
the ones that aren't valid and integrate the valid ones into the
documentation itself. Sometimes those who write the documentation may not
have thought of something, and a good user comment can make documentation
maintenance much easier.
So, while user comments may not be the best idea, I don't think it is an
idea that is completely without merit. Of course, as you suggest, ideas
are cheap (mine included). Suggesting user comments would be much better
bundled with some code. :-)
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
docs (was Re: mod_perl presence at OSCON (and other CONs) is at danger)
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Posted by "James.Q.L" <sh...@yahoo.com>.
> 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
Posted by Eric Berg <eb...@bergbrains.com>.
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 <eb...@bergbrains.com>
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
Posted by Frank Wiles <fr...@wiles.org>.
On Tue, 08 Jun 2004 17:43:23 -0400
Perrin Harkins <pe...@elem.com> 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 <fr...@wiles.org>
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
Posted by Chris Shiflett <sh...@php.net>.
--- Frank Maas <fr...@cheiron-it.nl> 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
Posted by Frank Maas <fr...@cheiron-it.nl>.
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
Posted by Larry Leszczynski <la...@emailplus.org>.
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
Posted by "dreamwvr@dreamwvr.com" <dr...@dreamwvr.com>.
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,
dreamwvr@dreamwvr.com
--
/* 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 0000 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: Domain Name PR
Posted by Larry Leszczynski <la...@emailplus.org>.
On Wed, 9 Jun 2004, gunther wrote:
> But still having modperl.com as a primary project-name
> related domain name would be there for people who can't type _.
Plus it will be consistent with other sites like modssl.org. In fact both
modssl.com and modssl.org exist, but modssl.com just redirects to
modssl.org. I think that scheme would be appropriate for
modperl.com/modperl.org too.
I also agree with the previous post that we shouldn't be creating domain
names with hyphens or underscores if there's the possibility of clients
out there that will not be able to handle them.
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: Domain Name PR was Re: mod_perl presence at OSCON (and other
CONs) is at danger
Posted by Stas Bekman <st...@stason.org>.
gunther wrote:
>
>
> Chris Shiflett wrote:
>
>> --- gunther <gu...@extropia.com> 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 _.
-1. the reason: if it works for some clients people will start linking to it,
and having other clients fail to connect.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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: Domain Name PR was Re: mod_perl presence at OSCON (and other CONs) is at danger
Posted by Patrick <pa...@patoche.org>.
gunther <gu...@extropia.com> 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
Domain Name PR was Re: mod_perl presence at OSCON (and other CONs)
is at danger
Posted by gunther <gu...@extropia.com>.
Chris Shiflett wrote:
>--- gunther <gu...@extropia.com> 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
Posted by Chris Shiflett <sh...@php.net>.
--- gunther <gu...@extropia.com> 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
Posted by gunther <gu...@extropia.com>.
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 "toolkits" or core "tools" like CMS systems). This
is part of a chicken and egg problem. On the one hand, if you have a lot
of apps, you are more likely to see adoption of the technology and if
the technology is well adopted, you are likely to see a lot more apps.
Along with the apps is the convincing of the ISPs to support mod_perl.
How many support PHP (A lot I would gather?) and how many support
mod_perl? I gather it's about 50 from the directory of ISPs on the
mod_perl site, but how actively do they really support mod_perl? Do they
support it? Or does it come by default along with PHP with every single
shared user www account someone gets for the going rate of 9.99$/month?
Another issue...
has anyone gone to the following URLs:
www.modperl.com -- a website for the "first" book but the link to the
real modperl site is actually buried way down as one of the links
www.modperl.org (some consulting firm called powerdata?)
www.mod_perl.com (doesn't exist)
www.mod_perl.org (doesn't exist)
For PR, I would think it would be nice for common URLs such as these to
be freed up and appropriately used or redirected to perl.apache.org
As an only semi-frequent user of perl.apache.org, I really prefer typing
www.modperl.com or .org and not having to remember the *.apache.org
convention. Call me crazy, but even though I use pubmed several times a
week, I still find myself just typing www.pubmed.com instead of the real
url: http://www.ncbi.nlm.nih.gov/entrez/query.fcgi. Similar concept.
Gosh, I guess I am being very negative in this email. Sorry if I come
across that way.
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.
I guess I should stop my spewing now. I wish everyone here luck in
promoting mod_perl.
Thanks,
Gunther
Re: mod_perl presence at OSCON (and other CONs) is at danger
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Chris" == Chris Shiflett <sh...@php.net> 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
<me...@stonehenge.com> <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
Posted by Chris Shiflett <sh...@php.net>.
--- Geoffrey Young <ge...@modperlcookbook.org> 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
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Perrin Harkins wrote:
> 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).
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.
--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
Posted by Chris Shiflett <sh...@php.net>.
--- Perrin Harkins <pe...@elem.com> 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
Posted by Perrin Harkins <pe...@elem.com>.
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: mod_perl presence at OSCON (and other CONs) is at danger
Posted by Chris Shiflett <sh...@php.net>.
--- Perrin Harkins <pe...@elem.com> 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: mod_perl presence at OSCON (and other CONs) is at danger
Posted by Perrin Harkins <pe...@elem.com>.
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
Posted by Chris Shiflett <sh...@php.net>.
--- Jie Gao <J....@isu.usyd.edu.au> 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
Shared Servers (Was: mod_perl presence at OSCON (and other CONs) is at danger)
Posted by Chris Shiflett <sh...@php.net>.
--- Perrin Harkins <pe...@elem.com> wrote:
> Actually, as I understand it, PHP has all the same problems. There
> is a "safe mode", but enabling it tends to break things, so many
> ISPs turn it off. Even with it on, I believe you can still redefine
> core functions at will, not to mention just coding something that
> will chew CPU or RAM until the server dies or an rlimit kills your
> process. I've been told that many PHP hosts actually run PHP
> through CGI for this reason. Please correct me if I'm wrong, Chris.
Pretty much, except for the purpose of safe_mode (which is probably the
most poorly named directive). The cheap Web hosts I've used seem to be
pretty good at suspending any account that is abusing its privileges (and
they will usually revoke it after investigating a bit further). So, I've
never had a problem with other users on the server adversely affecting my
experience. But, I think I keep my expectations in check when paying
$5-$10 a month.
The safe_mode directive is something that tries to address a specific
security problem, but it doesn't solve it at all. On a shared server, it's
pretty easy to write a PHP script (http://shiflett.org/code/browse.phps)
that will let you browse the filesystem with Apache's privileges. A lot of
PHP developers develop their business logic separate from presentation,
and they store these files outside of the Web tree. Of course, if you can
include this code from other scripts, it means Apache can read them, and
thus, so can my script. :-) With safe_mode, my PHP script won't work.
Problem solved? Not for me, since I also know Perl, and Perl doesn't care
about php.ini. :-) Of course, even a simple Bash CGI would work just fine.
So, I think safe_mode is both poorly named and useless. If someone *only*
knows PHP, they're not really the type of person I'm worried about anyway.
> Regardless, let's not go picking fights with PHP. PHP and Perl have
> a lot in common, and I would rather see people use PHP than a
> proprietary system. It's not necessary to attack PHP in order to
> promote Perl.
I think both are great. There is plenty to hate in PHP, and once you've
reached a certain point, you're aware of all the shortcomings pretty well.
:-) I have complaints about CVS, too, but I still use it. It's familiar
and gets the job done.
If you want to start picking fights with Java or Microsoft stuff, count me
in. :-)
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
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2004-06-09 at 09:56, James.Q.L wrote:
> > 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.
Actually, as I understand it, PHP has all the same problems. There is a
"safe mode", but enabling it tends to break things, so many ISPs turn it
off. Even with it on, I believe you can still redefine core functions
at will, not to mention just coding something that will chew CPU or RAM
until the server dies or an rlimit kills your process. I've been told
that many PHP hosts actually run PHP through CGI for this reason.
Please correct me if I'm wrong, Chris.
Regardless, let's not go picking fights with PHP. PHP and Perl have a
lot in common, and I would rather see people use PHP than a proprietary
system. It's not necessary to attack PHP in order to promote Perl.
- 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
Posted by "James.Q.L" <sh...@yahoo.com>.
--- Jie Gao <J....@isu.usyd.edu.au> 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
Re: mod_perl presence at OSCON (and other CONs) is at danger
Posted by Jie Gao <J....@isu.usyd.edu.au>.
On Tue, 8 Jun 2004, James.Q.L wrote:
> Date: Tue, 8 Jun 2004 22:26:15 -0700 (PDT)
> From: James.Q.L <sh...@yahoo.com>
> To: Modperl List <mo...@perl.apache.org>
> Subject: 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 ).
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 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?
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
Posted by "James.Q.L" <sh...@yahoo.com>.
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
Posted by Stefan Loones <st...@pandava.com>.
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 help to make things
better. I do have a lot of respect for the people here who spent so much
time supporting mod_perl !
Stef
Re: mod_perl presence at OSCON (and other CONs) is at danger
Posted by Perrin Harkins <pe...@elem.com>.
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
Posted by Stas Bekman <st...@stason.org>.
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 advocacy@perl 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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Posted by Eric Frazier <er...@dmcontact.com>.
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
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
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
Posted by Andy Armstrong <an...@hexten.net>.
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
Re: mod_perl presence at OSCON (and other CONs) is at danger
Posted by Eric <er...@dmcontact.com>.
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 <st...@stason.org> 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
><me...@stonehenge.com> <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
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Stas" == Stas Bekman <st...@stason.org> 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
<me...@stonehenge.com> <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
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Posted by Perrin Harkins <pe...@elem.com>.
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
Posted by Arnaud Blancher <Ar...@ungi.net>.
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
Posted by Perrin Harkins <pe...@elem.com>.
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.
> 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.
Thanks. I have a couple more articles in the pipeline about handling
specific issues, but not a comprehensive code example. The trouble is
that writing that kind of thing is generally too much work for just an
article.
If someone asked me for an example app to look at today, I would point
them at Krang (http://krang.sourceforge.net/). It is a complete working
application, not a toy or demo, and the code is well-organized and takes
advantage of many great CPAN modules. It uses a model-view-controller
design, and follows best practices for testing, portability, etc.
The only downside is that real applications are fairly complex, and
sometimes that makes it harder to learn from them. No one has done a
better job of demonstrating the basic concepts in a short article than
Kake, with her "How to Avoid Writing Code" story:
http://www.perl.com/pub/a/2003/07/15/nocode.html
> 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.
- 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
Posted by Frank Wiles <fr...@wiles.org>.
On Tue, 08 Jun 2004 06:19:41 -0700
Stas Bekman <st...@stason.org> 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 <fr...@wiles.org>
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
Posted by Stas Bekman <st...@stason.org>.
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/Pine.LNX.4.30.0102121648320.27126-100000@stas.extropia
>
> 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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Posted by Stas Bekman <st...@stason.org>.
Jim Martinez wrote:
> 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.
But that's not an OSCON Wiki! To submit an OSCON BOF one needs to go here:
http://conferences.oreillynet.com/pub/w/29/bof.html
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Posted by Jim Martinez <jj...@bigbigorg.org>.
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
Posted by Perrin Harkins <pe...@elem.com>.
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
Posted by Jim Martinez <jj...@bigbigorg.org>.
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/Pine.LNX.4.30.0102121648320.27126-100000@stas.extropia
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
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Posted by Perrin Harkins <pe...@elem.com>.
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
Re: mod_perl presence at OSCON (and other CONs) is at danger
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
[...]
> So if you enjoy your mod_perl job and want to continue so in the future,
> make sure that you come to the mod_perl tutorials and presentations at
> OSCon and other big conferences.
>
> Here is the OSCon info.
> http://conferences.oreillynet.com/os2004/
>
> p.s. the deadline for tutorial cutoffs (at least 20 attendees) is June
> 21th. So if you were planning to go to the tutorials, make sure you
> register (or add the tutorials if you already did) before that date.
As Geoff has just mentioned to me, both mod_perl tutorials at the
upcoming OSCon2004 are not only not cancelled, but are now SOLD OUT [1][2].
Thanks to everybody who has signed up. Hopefully this will be a good
reason to accept more mod_perl talks/tutorials next year.
[1] http://conferences.oreillynet.com/cs/os2004/view/e_sess/5082
[2] http://conferences.oreillynet.com/cs/os2004/view/e_sess/5042
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
ModPerl and Perl on darwin jaguar/panther
Posted by plumber <pl...@gnu-darwin.org>.
ModPerl and Perl on darwin jaguar/panther
http://plumber.gnu-darwin.org/
Regards
-----BEGIN PLUMBER CODE BLOCK-----
Version: 1.0
¬ | | > Regards Plumber || GNU Darwin.
¬ | | > OOP --\///\ (0)=(0) Darwin/Power Mac G4.
¬ | | > ( __ò ó__ ) The best for Fede ¬ \\\ federicafontana.it ¬
------END PLUMBER CODE BLOCK------
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GMU/S d+@ s: a- K+++++ PGP++++ K---- dpu s--:-- C++++ C-- B L X U++++
P+++ C-- P! L--- E+++ W+++ P! L--- N+++ o-- K+++++
------END GEEK CODE BLOCK------
--
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
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Posted by Gerald Richter <ri...@ecos.de>.
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 Richter ecos electronic communication services gmbh
IT-Securitylösungen * Webapplikationen mit Apache/Perl/mod_perl/Embperl
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de 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