Re: Putting together the TPC mod_perl track
"Stas" == Stas Bekman [EMAIL PROTECTED] writes: Stas I know that people pay a lot of money to attend TPC, compared to Stas YAPC, but I doubt that people would complain about a few laughs. They've never complained at any of my seminars, and I bill myself as a "technical comedian". Humor helps the learning process, as long as it isn't used to distract people from poor materials. So we work hard at putting good quality into the materials first, and then adding the layer of humor at the right moments. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Putting together the TPC mod_perl track
Stas et al, Since its getting towards the end of the year, should we be thinking of putting together a mod_perl track for TPC? Has anyone got any ideas on what they'd like to either a) talk about, or b) hear talks about ? Well, we have planned to announce the CFP when Nathan will give it to the mod_perl PMC (project management committee) back in September. But as we are all overworked, things got delayed :( So I guess Nat, will send the CFP soon to us. When everything is ready we probably will have a mailing list, where we will discuss all the details. I don't think this list is the right place to have the discussion on as it might generate huge threads... but we will see. So far, as I understood Ask and me are on the paper approval committe with Nat serving as our big boss :) It's possible that other pmc members will lend us a hand when and if they will have a chance :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Putting together the TPC mod_perl track
On Wed, 1 Nov 2000, Nathan Torkington wrote: Matt Sergeant writes: Since its getting towards the end of the year, should we be thinking of putting together a mod_perl track for TPC? I've got a room allocated to mod_perl for two days of conference at the next OScon. With this group's blessing I'd like to call it "the mod_perl conference", as nobody else is offering mod_perl this kind of exposure. It'll be mentioned in TPC advertising, but it won't be a Perl or Apache track of the conference: it'll be labelled and promoted as mod_perl only. Wow, Nat, you are the man!!! Thanks a lot! I'm looking forward for all the details about the length of the talks, that we have discussed before. The low-hanging fruit (obvious topics) will be: * Doug MacEachern on mod_perl 2 * Matt on AxKit (also likely to make an appearance in the XML track) * Brian on AO (please please dark gods let AO come to fruition) * talk(s) on how to do good things with Apache::ASP * mod_perl + backhand = ass-kicking * Tips for developing or tuning HTML::Mason sites * Case studies showing how big companies use mod_perl + HTML::Emperl, + Template Toolkit, + one room will be completely occupied by Damian Conway. We have to collect $110 grands to buy him out from the Perl track. YAS, has already agreed to help with $55,000 that were collected so far. So only $55,000 are left to collect. +multilingual sites with mod_perl and TT, (I think Eric Cholet will be the speaker for that, since he has implmented it here at jazzvalley.com) + using mod_perl for the most successful money making model on the web == xxx sites, with an extensive demo. + All the usual beginners + performance stuff + latest slides from Doug's snowball experience. We are all interested to know how our leaders spend their time when they are not coding mod_perl. + Geoff with hundreds of his cool modules that he has released and will release till the conference, so we call it's Apache::Geoff + May be jwb to talk about database performance coding/ Apache::Session. + more to come. BTW, if you have something to talk about that isn't really useful, but very funny, you should propose it as well. Dave Cross' talk about Sub::Approx at YAPC::Europe was the killer talk. Remember that learning new things is nice, but having a few minutes of fun is even nicer :) This latter is an important part of the Perl conference. Many companies who would never 'fess up to using Perl seem quite happy to send employees to speak at conferences. Their talks end up as a big advertisement for Perl, and lets us name-drop the company as a Perl user. I see no reason why the same shouldn't happen with mod_perl. Yup, definitely! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Putting together the TPC mod_perl track
Stas Bekman [EMAIL PROTECTED] writes: BTW, if you have something to talk about that isn't really useful, but very funny, you should propose it as well. Dave Cross' talk about Sub::Approx at YAPC::Europe was the killer talk. Remember that learning new things is nice, but having a few minutes of fun is even nicer :) Hey, I liked the Perl 12 Step thing that whatsisname did as well. Oh yes, that would've been me. -- Piers (Ego? Me?)
Re: Putting together the TPC mod_perl track
Stas Bekman [EMAIL PROTECTED] writes: BTW, if you have something to talk about that isn't really useful, but very funny, you should propose it as well. Dave Cross' talk about Sub::Approx at YAPC::Europe was the killer talk. Remember that learning new things is nice, but having a few minutes of fun is even nicer :) Hey, I liked the Perl 12 Step thing that whatsisname did as well. Oh yes, that would've been me. Sorry about not mentioning all the other speakers who have added to the YAPC fun. Nat was there, so we will make sure to bring at least a little of this fun to TPC. I know that people pay a lot of money to attend TPC, compared to YAPC, but I doubt that people would complain about a few laughs. Nat? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Putting together the TPC mod_perl track
Stas Bekman writes: Sorry about not mentioning all the other speakers who have added to the YAPC fun. Nat was there, so we will make sure to bring at least a little of this fun to TPC. I know that people pay a lot of money to attend TPC, compared to YAPC, but I doubt that people would complain about a few laughs. Nat? Laughs, yes. Chaos, no. The Perl Golf from this year taught me that. Chaos works well at a YAPC. People get tetchy about it when they pay TPC rates for a conference. Nat
Re: Putting together the TPC mod_perl track
Could someone please tell me where and when this conference will be held? Also, how do I go about registering to attend? Many Thanks, Trey - Original Message - From: Nathan Torkington [EMAIL PROTECTED] To: Matt Sergeant [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 01, 2000 11:14 AM Subject: Re: Putting together the TPC mod_perl track Matt Sergeant writes: Since its getting towards the end of the year, should we be thinking of putting together a mod_perl track for TPC? I've got a room allocated to mod_perl for two days of conference at the next OScon. With this group's blessing I'd like to call it "the mod_perl conference", as nobody else is offering mod_perl this kind of exposure. It'll be mentioned in TPC advertising, but it won't be a Perl or Apache track of the conference: it'll be labelled and promoted as mod_perl only. The low-hanging fruit (obvious topics) will be: * Doug MacEachern on mod_perl 2 * Matt on AxKit (also likely to make an appearance in the XML track) * Brian on AO (please please dark gods let AO come to fruition) * talk(s) on how to do good things with Apache::ASP * mod_perl + backhand = ass-kicking * Tips for developing or tuning HTML::Mason sites * Case studies showing how big companies use mod_perl This latter is an important part of the Perl conference. Many companies who would never 'fess up to using Perl seem quite happy to send employees to speak at conferences. Their talks end up as a big advertisement for Perl, and lets us name-drop the company as a Perl user. I see no reason why the same shouldn't happen with mod_perl. Nat
Putting together the TPC mod_perl track
Stas et al, Since its getting towards the end of the year, should we be thinking of putting together a mod_perl track for TPC? Has anyone got any ideas on what they'd like to either a) talk about, or b) hear talks about ? -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
RE: Putting together the TPC mod_perl track
Hi Geoff, On Wed, 1 Nov 2000, Geoffrey Young wrote: pretty basic, stuff like that... I think that's what's needed. 73, Ged.
Re: Putting together the TPC mod_perl track
Matt Sergeant writes: Since its getting towards the end of the year, should we be thinking of putting together a mod_perl track for TPC? I've got a room allocated to mod_perl for two days of conference at the next OScon. With this group's blessing I'd like to call it "the mod_perl conference", as nobody else is offering mod_perl this kind of exposure. It'll be mentioned in TPC advertising, but it won't be a Perl or Apache track of the conference: it'll be labelled and promoted as mod_perl only. The low-hanging fruit (obvious topics) will be: * Doug MacEachern on mod_perl 2 * Matt on AxKit (also likely to make an appearance in the XML track) * Brian on AO (please please dark gods let AO come to fruition) * talk(s) on how to do good things with Apache::ASP * mod_perl + backhand = ass-kicking * Tips for developing or tuning HTML::Mason sites * Case studies showing how big companies use mod_perl This latter is an important part of the Perl conference. Many companies who would never 'fess up to using Perl seem quite happy to send employees to speak at conferences. Their talks end up as a big advertisement for Perl, and lets us name-drop the company as a Perl user. I see no reason why the same shouldn't happen with mod_perl. Nat
Re: Putting together the TPC mod_perl track
On Wed, 1 Nov 2000, Matt Sergeant wrote: Has anyone got any ideas on what they'd like to either a) talk about, or b) hear talks about ? I was thinking of giving a talk on Mason unless Jon Swartz wants to (haven't asked him yet). I also have another planned but its not mod_perl specific (technically, Mason isn't either, I guess). -dave /*== www.urth.org We await the New Sun ==*/
Re: Putting together the TPC mod_perl track
I wrote: I've got a room allocated to mod_perl for two days of conference at the next OScon Man, that'll teach me to open my big mouth :-) OScon is O'Reilly's Open Source Convention. Next year it will be in San Diego. See http://conferences.ora.com/ for a link to this year's OScon. OScon has several tracks on things like Apache, Python, PHP, etc., as well as The Perl Conference. I don't have a layout or blurb for this year's convention, because we're still planning it. The layout of tracks is gelling. The CFP is supposed to go out in a week's time, a target that may or may not be reached. Nat
Re: Putting together the TPC mod_perl track
what is AO? thanks marc - Original Message - From: "Nathan Torkington" [EMAIL PROTECTED] To: "Matt Sergeant" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 01, 2000 12:14 PM Subject: Re: Putting together the TPC mod_perl track Matt Sergeant writes: Since its getting towards the end of the year, should we be thinking of putting together a mod_perl track for TPC? I've got a room allocated to mod_perl for two days of conference at the next OScon. With this group's blessing I'd like to call it "the mod_perl conference", as nobody else is offering mod_perl this kind of exposure. It'll be mentioned in TPC advertising, but it won't be a Perl or Apache track of the conference: it'll be labelled and promoted as mod_perl only. The low-hanging fruit (obvious topics) will be: * Doug MacEachern on mod_perl 2 * Matt on AxKit (also likely to make an appearance in the XML track) * Brian on AO (please please dark gods let AO come to fruition) * talk(s) on how to do good things with Apache::ASP * mod_perl + backhand = ass-kicking * Tips for developing or tuning HTML::Mason sites * Case studies showing how big companies use mod_perl This latter is an important part of the Perl conference. Many companies who would never 'fess up to using Perl seem quite happy to send employees to speak at conferences. Their talks end up as a big advertisement for Perl, and lets us name-drop the company as a Perl user. I see no reason why the same shouldn't happen with mod_perl. Nat
Re: Putting together the TPC mod_perl track
On Wed, 1 Nov 2000, Marc Spitzer wrote: what is AO? A port of the servlets architecture to mod_perl. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: Putting together the TPC mod_perl track
On Wed, 1 Nov 2000, Nathan Torkington wrote: * Case studies showing how big companies use mod_perl This latter is an important part of the Perl conference. Many companies who would never 'fess up to using Perl seem quite happy to send employees to speak at conferences. Their talks end up as a big advertisement for Perl, and lets us name-drop the company as a Perl user. I see no reason why the same shouldn't happen with mod_perl. I may be able to offer something on how we use mod_perl at eToys. We recently rewrote our codebase to take better advantage of mod_perl and are using some fun OO stuff, as well as a bunch of scalability tricks. I was also thinking about presenting a comparison of templating methods and modules. - Perrin
Re: Putting together the TPC mod_perl track
On Wed, 1 Nov 2000, Matt Sergeant wrote: On Wed, 1 Nov 2000, Marc Spitzer wrote: what is AO? A port of the servlets architecture to mod_perl. from the original announcement i sent on 4 sept 2000: README snip-- AO is a servlet engine for Perl. It provides an application environment with such features as session tracking and persistence, security (authentication and authorization), simple configuration, and customizable logging. It also eventually will implement a Perl version of the (Java) Servlet API, providing applications with a well known model for application construction that abstracts the process model and deployment environment away from the developer. -- AO integrates out of the box with Apache::Session and Mason. i'm hoping others will add integration with AxKit, HTML::Template, Embperl, ASP, etc. the plugin architecture allows for us to provide even more implementations of session tracking and persistence, credential checking, role authorization, etc, or even to replace the core subsystems themselves. the adapter architecture will eventually allow us to run AO apps in either an external perl process or using today's in-process model - without modifications either way. the addition of the Servlet API will add a featureful, robust interface to the web application environment provided by the servlet engine. this is my first release of AO to the outside world. it's a pre-pre-pre-developer release; much is unfinished or in need of rework, altho i am using the engine as is for several projects today. i'm interested in feedback on both the general goals of the software as well as on its architecture and implementation. there's no mailing list, so please either send mail to me directly or to the modperl mailing list (preferred). PLEASE read the README before you do anything else.
Re: Putting together the TPC mod_perl track
Perrin Harkins writes: I may be able to offer something on how we use mod_perl at eToys. We recently rewrote our codebase to take better advantage of mod_perl and are using some fun OO stuff, as well as a bunch of scalability tricks. I was also thinking about presenting a comparison of templating methods and modules. That'd be really cool. We'll post a CFP as soon as we know exactly what's going on. The CFP will explain just what information we want (probably title, brief description, outline, and author information). Thanks, Nat
Re: Putting together the TPC mod_perl track
On Wed, 1 Nov 2000, Nathan Torkington wrote: * Case studies showing how big companies use mod_perl This latter is an important part of the Perl conference. Many companies who would never 'fess up to using Perl seem quite happy to send employees to speak at conferences. Their talks end up as a big advertisement for Perl, and lets us name-drop the company as a Perl user. I see no reason why the same shouldn't happen with mod_perl. At the last US ApacheCon I did a talk on how we do XML/modperl related stuff for our publishing model at MP3.com, Inc. I have since then changed companies, so I can't really talk about that anymore (still got slides on my personal site though). The only thing I can really talk about is my current experiences in regards to i18n with the mailing list archives at http://archive.covalent.net/, but that would be pretty boring I would think. Cheers, -- Sander van Zoest [[EMAIL PROTECTED]] Covalent Technologies, Inc. http://www.covalent.net/ (415) 536-5218 http://www.vanzoest.com/sander/
Re: Putting together the TPC mod_perl track
I'd be curious to know how this is working out as we already have something similar and have been working on it for a couple years in evolution where Java Servlet compatibility was a key (but I'll admit -- not a #1) component to our design process. The stuff we've done emulates servlet architecture as greatly as we felt was possible without (A) forcing anyone to use a particular templating language (ie JSP style) although I have to say that I really liked Matt Sergeant's Perl-style XSP layer in AxKit at the conference. We've really started growing used to the JSP template model and so, seeing it implemented in Perl (Albeit more powerful for XML) was very interesting. (B) performance (this is a key component that Perl doesn't do well if forced to do everything servlet-style etc. (C) Not forcing Perl users to use a method call convention that is inconsistent with Perl. eg It's making our session wrappers around Apache::Session that emulate the Java Servlet Session API was OK because it's an external class. But IMHO emulating an event driven doPost and doGet method that needs to be overridden is a bit of overkill and we found confusing to our community of developers that are used to CGI.pm syntax. Why force them to switch? It emulates the architecture so closely that it took us only a couple months this summer to port nearly all the object interfaces, some significant drivers and have converted one of the hardest apps in Perl into Java Servlets - Perl. In Perl we have many apps in production, but in Java, we have one app (which we felt was the most representative to convert first). Now that we have the Java Servlet behind us, we believe every subsequent Perl app we do in our current architecture will take very little time (days to weeks depending on complexity) to switch over to Java based on real-world experience. And vice versa. With most of the work being the Views (which are View objects in our Perl architecture and JSPs in Java)... Ultimately we'd like to move to View objects just being taglib controllers for a template language. Not surprisingly, things that were easy in Perl, we had write stuff for in Java. So actually the same thing could be said of Java -- that Java people would really enjoy a Perl way of doing things if given classes to do so. eg in Perl, Perl Code can = Config File. But in Java, you really need something nicer like an XML based config because no one wants to download an app and have to recompile a Java class to set it up. Setting properties in a servlet engine sucks because there are effectively over 300 properties we allow setting (with many defaults) in WebDB. And placing them in a singleton sucks because you want people to be able to run different apps on the same web server without having to have multiple copies of the app. Both our Perl and Java use a framework similar to those discussed in the two main Apache.org Java servlet framework projects: http://java.apache.org/turbine/model2+1.html and http://jakarta.apache.org/struts/index.html At 01:33 PM 11/1/00 -0800, brian moseley wrote: On Wed, 1 Nov 2000, Matt Sergeant wrote: On Wed, 1 Nov 2000, Marc Spitzer wrote: what is AO? A port of the servlets architecture to mod_perl. from the original announcement i sent on 4 sept 2000: README snip-- AO is a servlet engine for Perl. It provides an application environment with such features as session tracking and persistence, security (authentication and authorization), simple configuration, and customizable logging. It also eventually will implement a Perl version of the (Java) Servlet API, providing applications with a well known model for application construction that abstracts the process model and deployment environment away from the developer. -- AO integrates out of the box with Apache::Session and Mason. i'm hoping others will add integration with AxKit, HTML::Template, Embperl, ASP, etc. the plugin architecture allows for us to provide even more implementations of session tracking and persistence, credential checking, role authorization, etc, or even to replace the core subsystems themselves. the adapter architecture will eventually allow us to run AO apps in either an external perl process or using today's in-process model - without modifications either way. the addition of the Servlet API will add a featureful, robust interface to the web application environment provided by the servlet engine. this is my first release of AO to the outside world. it's a pre-pre-pre-developer release; much is unfinished or in need of rework, altho i am using the engine as is for several projects today. i'm interested in feedback on both the general goals of the software as well as on its architecture and implementation. there's no mailing list, so please either send mail to me directly or to the modperl mailing list (preferred). PLEASE read the README before you do anything else.
