This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: mod_perl List <modperl@apache.org> From: "Keith G. Murphy" <keithmur@mindspring.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Fri, 19 Oct 2001 12:55:03 -0500 Andrew Ho wrote: > > Hello, > > I checked the list archives and it didn't look like this had been posted yet. > For those of you who haven't seen it yet... a great read on perl.com about > the Apache/mod_perl setup at eToys, co-authored by our own mod_perl > regular contributer Perrin Harkins. > > http://www.perl.com/pub/a/2001/10/17/etoys.html That's so awesome, the single best piece of technical writing on the web I can remember in a long time. Thanks for sharing. By the way, I noticed he documented still another gotcha due to a sneaky closure. Does anyone know off-hand whether the Perl 6 folks plan to change the closure syntax so they don't sneak into your code this way? I wonder how many mod_perl authors have never been burned by one? === To: <keithmur@mindspring.com>, "mod_perl List" <modperl@apache.org> From: "Jeremy Howard" <jh_lists@fastmail.fm> Subject: Re: [OT] Excellent article on Apache/mod_perl at eToys Date: Sat, 20 Oct 2001 10:48:08 +1000 > By the way, I noticed he documented still another gotcha due to a sneaky > closure. Does anyone know off-hand whether the Perl 6 folks plan to > change the closure syntax so they don't sneak into your code this way? > Closures, references, et al are being thoroughly revised, such that there will be far fewer gotchas. However, these kinds of memory leaks will be less of an issue anyway because Perl 6 will be garbage collected. Also, proper exception handling will be built into the language. PS: I haven't seen many of the regulars here on the Perl 6 lists. There's both language design and internals streams currently happening, so everyone's interests and skills should be catered for. Please have a look at http://dev.perl.org and consider getting involved. It's interesting work and there's a similarly positive and intellectual spirit on the P6 lists to what we experience here. === To: "mod_perl List" <modperl@apache.org> From: "Perrin Harkins" <perrin@elem.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Fri, 19 Oct 2001 09:49:37 -0400 Thanks to all for the kind words. This article actually went up a little bit before it was supposed to, and there should be a revision going up soon with some grammatical fixes and a set of graphics to illustrate parts of it. I'll post a follow-up when that happens in case anyone wants to go and look at the pretty pictures. While we're on the subject, thanks to everyone who contributed to the many open source projects that we used. We couldn't have done it without you. === To: "Clinton Gormley" <Clinton.Gormley@virginwines.com>, From: "Perrin Harkins" <perrin@elem.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Fri, 19 Oct 2001 11:12:14 -0400 > What I'd love to see is the avg spec and numbers of machines in each > section. So how many proxy, mod_perl and search servers were required to > give the phenomenal performance you managed to achieve. Well, this was a long time ago (I wrote the article over a year ago), and I don't remember exactly. The proxy machines were pretty basic, the search servers were heavy on CPU power, and the mod_perl servers were heavy on RAM. There were a lot of machines in the cluster, but I don't remember exactly how many and it changed over time. There were dozens of mod_perl servers when the cluster was at its biggest. Most of them were idle for the majority of the time, but they were all needed for the occasional peak load. I remember at one point I was feeling embarrassed about the number of machines and I told one of our sysadmins that it might have been a better strategy to get a big Sun box or two instead. He replied that a Sun box with equivalent power would have cost about 10 times as much as what we paid for our rackmounted Intel machines. After that, I didn't worry about it too much. - Perrin === To: Perrin Harkins <perrin@elem.com> From: Tom Servo <tomservo@cnw.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Fri, 19 Oct 2001 10:36:17 -0700 (PDT) If memory serves, I think we had something like 20-30 proxy servers and I think, at the end, we had w21 through w112 for app servers, so something like 92 app servers. I don't remember how many search boxes though. Thanks for the article Perrin, I didn't know half of what you, Ollie, Chris, Adam, Doug, and others had put together. And secondly, thanks for teaching me all the stuff you did, I feel pretty lucky to have worked with you there. === To: modperl@apache.org From: Thomas Klausner <domm@zsi.at> Subject: [OT] Re: Excellent article on Apache/mod_perl at eToys Date: Fri, 19 Oct 2001 20:00:15 +0200 Hi! On Fri, Oct 19, 2001 at 09:59:18AM -0400, Drew Taylor wrote: > What I found most interesting was the detail of the extensive caching which > was implemented to survive the seasonal rush. Wasn't this "seasonal rush" at least partly caused by the so-called toywar (www.toywar.com) between eToys.com (the online retailer) and etoy.com (the art group)? As far as I remember this incident, eToys.com sued etoy.com (who were holding this domain since 1994) because of trademark delusion etc., which caused one of the first distrubuted DOS attacks against etoys.com. see: http://rtmark.com/etoymain.html === To: <modperl@apache.org>, "Thomas Klausner" <domm@zsi.at> From: "Perrin Harkins" <perrin@elem.com> Subject: Re: [OT] Re: Excellent article on Apache/mod_perl at eToys Date: Fri, 19 Oct 2001 14:19:28 -0400 > Wasn't this "seasonal rush" at least partly caused by the so-called toywar > (www.toywar.com) between eToys.com (the online retailer) and etoy.com > (the art group)? There were a lot of DoS attacks (and some even uglier, nastier ones) in 1999 as a result of that. Most of that was dealt with through standard access control stuff, plus the throttling code that was mentioned in the article. The 2000 rush, which we built this new system for, was real customer traffic, although there's always some joker with a bot trying to buy all the PlayStation 2 units. === To: mod_perl List <modperl@apache.org> From: Matthew Kennedy <mkennedy@opushealthcare.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: 22 Oct 2001 10:13:15 -0500 Firstly, I am curious... Why was Berkeley DB chosen for caching when a RDBMS (mysql in this case) was already being used? Secondly, I've worked on a good-sized commerce site with mod_perl+HTML::Mason. One of the more dirty secrets is that the back-end of the site involves several standalone perl programs running as daemons. What's even worse is; most of them have to sit in poll/wait loops waiting on message from external systems (such as pop3 servers, ccvs etc.) For comparions, a nice aspect of j2ee applications IMHO is the "application server" tends to be more general. ie. the application server is not just the web server (as it is with mod_perl). I've found j2ee features such as message beans, queues and such especially useful for back-end work. For these reasons, I personally don't buy the argument that mod_perl makes an effective application server for a good sized task (your mileage will vary no doubt ;). So again, I'm curious, what does the eToys.com site back-end stuff look like? Great article BTW, Bill & Perrin, === To: "Matthew Kennedy" <mkennedy@opushealthcare.com>, From: "Robert Koberg" <rob@koberg.com> Subject: RE: Excellent article on Apache/mod_perl at eToys Date: Mon, 22 Oct 2001 18:14:25 -0700 > For comparions, a nice aspect of j2ee applications IMHO is the > "application server" tends to be more general. ie. the application > server is not just the web server (as it is with mod_perl). I've found > j2ee features such as message beans, queues and such especially useful > for back-end work. For these reasons, I personally don't buy the > argument that mod_perl makes an effective application server for a good > sized task (your mileage will vary no doubt ;).> > What is stopping you from using both, if you want? === To: Matthew Kennedy <mkennedy@opushealthcare.com>, From: Perrin Harkins <perrin@elem.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Mon, 22 Oct 2001 22:27:42 -0400 on 10/22/01 11:13 AM, Matthew Kennedy at mkennedy@opushealthcare.com wrote: > Why was Berkeley DB chosen for caching when a RDBMS (mysql in this case) > was already being used? It's faster and less resource-intensive for this kind of thing. We just wanted a really fast persistent hash, and didn't need SQL or relational concepts. > Secondly, I've worked on a good-sized commerce site with > mod_perl+HTML::Mason. One of the more dirty secrets is that the back-end > of the site involves several standalone perl programs running as > daemons. What's even worse is; most of them have to sit in poll/wait > loops waiting on message from external systems (such as pop3 servers, > ccvs etc.) It sounds like the limitation there is that you're interfacing with systems that can't notify you when something new happens. That's not Perl's fault. If you wrote your daemons in Java alpahabet soup, they'd still have to poll the pop3 server. > For comparions, a nice aspect of j2ee applications IMHO is the > "application server" tends to be more general. ie. the application > server is not just the web server (as it is with mod_perl). I've found > j2ee features such as message beans, queues and such especially useful > for back-end work. For these reasons, I personally don't buy the > argument that mod_perl makes an effective application server for a good > sized task (your mileage will vary no doubt ;). I guess it all depends on what you think "application server" means. In our case, it was a server that ran code persistently, which supported an HTTP interface. It wasn't our front-end web server, and we could run anything we wanted to in it. Lots of people implement reliable queues in Perl. They generally use something like an RDBMS or Berkeley DB (which has a queue option) for the backing store. Many JMS implementations use an RDBMS for all the hard stuff as well. > So again, I'm curious, what does the eToys.com site back-end stuff look > like? The web site part that was discussed in the article ended at the Oracle database. There was a system built on Oracle's queuing technology that replicated orders to a backend system for processing. I believe the last revision of that was largely in PL/SQL. I don't know much about it, since there was an entirely different team working on it. === To: "Robert Koberg" <rob@koberg.com>, From: Gunther Birznieks <gunther@extropia.com> Subject: RE: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 16:45:00 +0800 At 09:14 AM 10/23/2001, Robert Koberg wrote: > > For comparions, a nice aspect of j2ee applications IMHO is the > > "application server" tends to be more general. ie. the application > > server is not just the web server (as it is with mod_perl). I've found > > j2ee features such as message beans, queues and such especially useful > > for back-end work. For these reasons, I personally don't buy the > > argument that mod_perl makes an effective application server for a good > > sized task (your mileage will vary no doubt ;).> > > >What is stopping you from using both, if you want? It's generally quite tough to convince management that maintaining two sets of knowledge -- Java and Perl is cost effective. I suppose it depends on the size of the organization but "consolidation" of "standards" in an organization is an age-old thing (eg move all servers to NT, move everyone to Java, etc...) Whether this actually saves costs is a bit of an arguement probably not best for this mailing list. However, I would have to say that I "feel" like coding middleware in Java is easier and more standardized, and well documented. But I "feel" like coding front-end web applications is much easier in Perl where the workflow bits change all the time. For this, I like using SOAP on the backend Java server and SOAP on the front-end Perl. YMMV. And I don't know that many organizations which will allow such a heterogeneous environment unless a vendor installs it as a turnkey solution and is willing to deal with all the support. === To: "'Gunther Birznieks'" <gunther@extropia.com>, From: Matt Sergeant <msergeant@startechgroup.co.uk> Subject: RE: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 09:55:03 +0100 > However, I would have to say that I "feel" like coding > middleware in Java > is easier and more standardized, and well documented. OK, so what are we missing? I feel like we're getting pretty close to standardisation of middleware development with environments like POE (which rocks, but is under-documented and still quite hard to grok), but maybe there's more we can do - and having people like yourself who cross the divide can only help if you give us more information :-) One thing I know is missing in the XML world is an equivalent to JAXP. Hopefully we'll put that right fairly soonish. I guess there's equivalent issues in the whole Perl "middleware" environment, but we don't really know what they are. === To: modperl@apache.org From: Rob Nagler <nagler@bivio.net> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 06:46:13 -0600 > is easier and more standardized, and well documented. But I "feel" like > coding front-end web applications is much easier in Perl where the workflow > bits change all the time. For this, I like using SOAP on the backend Java > server and SOAP on the front-end Perl. I don't quite understand the difference between workflow in the front-end and workflow in the back-end. They both change. The danger of making one part of the system easier to change is that people tend to "cheat". They won't put the business logic in the back-end if it takes twice as long. To me, the major issue in Perl vs Java is dynamic vs static typing. Building large scale systems in Perl is much like building them in Smalltalk or Lisp. It takes a certain mindset. The lack of compiled interfaces means you need much more discipline (e.g. unit testing). The payoff is big with Perl, because you can refactor more easily and quickly than in Java. The libraries aren't much an issue. A good example is SOAP. SOAP is middleware. It is standardized, documented, and the rest of it. You like it for connecting Perl to Java, but why can't it be the other way around? If it can be the other way around, why aren't Perl and Java equally adapted to building middleware applications? Rob === To: Matthew Kennedy <mkennedy@opushealthcare.com> From: wsheldah@lexmark.com Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 09:17:07 -0400 Matthew Kennedy wrote: > Secondly, I've worked on a good-sized commerce site with > mod_perl+HTML::Mason. One of the more dirty secrets is that the back-end > of the site involves several standalone perl programs running as > daemons. What's even worse is; most of them have to sit in poll/wait > loops waiting on message from external systems (such as pop3 servers, > ccvs etc.) Why exactly is that a dirty secret? I've been thinking about writing one or two standalone poe daemons to handle interfacing with other systems, and it doesn't seem like such a bad idea. Code to talk to or listen to web clients can be in mod_perl, and code to talk to other systems can be outside. I've even thought about taking some of the database objects out of mod_perl, but am less sure about doing that. Is anyone else using independent perl processes in a web app, or have strong reasons not to? === To: Matt Sergeant <msergeant@startechgroup.co.uk> From: Perrin Harkins <perrin@elem.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 09:45:36 -0400 Matt Sergeant wrote: > OK, so what are we missing? Based on the comments I've seen here over the years, and some on Slashdot, the thing that seems to worry people the most is the lack of an obvious message queue API in Perl. I've seen plenty of implementations, but there isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order. === To: modperl@apache.org From: Leon Brocard <acme@astray.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 15:36:53 +0100 Perrin Harkins sent the following bits through the ether: > Perhaps a port of JMS is in order. Interestingly, I've been thinking along the same lines. Spread (http://www.spread.org/) can be used for the publish/subscribe messaging domain but queueing seems to be important too. Straying a bit offtopic perhaps, but I wonder what would be involved... === To: Rob Nagler <nagler@bivio.net>, modperl@apache.org From: Gunther Birznieks <gunther@extropia.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 23:09:22 +0800 At 08:46 PM 10/23/2001, Rob Nagler wrote: > > is easier and more standardized, and well documented. But I "feel" like > > coding front-end web applications is much easier in Perl where the workflow > > bits change all the time. For this, I like using SOAP on the backend Java > > server and SOAP on the front-end Perl. > >I don't quite understand the difference between worflow in the front-end and >workflow in the back-end. They both change. The danger of making one part >of the system easier to change is that people tend to "cheat". They won't >put the business logic in the back-end if it takes twice as long. Yes, people can cheat. But generally the workflow that is most likely to change is the UI based workflow. UI isn't just about templates, it's a lot about how you go from one screen to the next, or not. Actually business logic is a bit of a misnomer because there is plenty of business logic in the front-end from your choice of fields to the javascript to the UI workflow. >To me, the major issue in Perl vs Java is dynamic vs static typing. Building >large scale systems in Perl is much like building them in Smalltalk or Lisp. >It takes a certain mindset. The lack of compiled interfaces means you need >much more discipline (e.g. unit testing). The payoff is big with Perl, >because >you can refactor more easily and quickly than in Java. I don't think refactoring in Perl is necessarily faster. Actually, it can be quite hard to refactor in Perl as well but for the opposite reason. If you do not have a strongly typed system, then when you break apart and rebuild another part of the system, Perl may very well not complain when a subtle bug comes up because of the fact that it is not strongly typed. Whereas Java will complain quite often and usually early with compile time checking. Compile time checking can definitely be a friend of yours especially when dealing with large systems. But it's also a friend that's judgemental (strongly typed) so he's a pain to drag along to a party.... In practice, I still think using a good framework, it's about as long to develop in Perl as it is in Java for a medium sized system. My only beef I have with Java and I still have it is that the debugging support is simply atrocious for web apps. Perl has many more debugging utilities and allows much greater introspection. When I develop in Java, the only reason it takes me about 20% longer is that I am restarting the server much more often than I do in Perl. >The libraries aren't much an issue. A good example is SOAP. SOAP is >middleware. It is standardized, documented, and the rest of it. You like >it for connecting Perl to Java, but why can't it be the other way around? >If it can be the other way around, why aren't Perl and Java equally adapted >to building middleware applications? Java's support for multi-threading makes writing servers feel fairly trivial with no jumping through IPC::Shared memory stuff hoops to get shared memory caches and the like.. you just synchronize on global data structures. Arguably, an overuse of threads has problems in itself, but in general, I think it is easier. It is also easier to find programmers who know how to code middleware that do Java and harder to find people who have coded middleware that are Perl programmers... so maybe the language would support it, but there is also a personnel issue. === To: Perrin Harkins <perrin@elem.com>, From: Gunther Birznieks <gunther@extropia.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 23:27:56 +0800 At 09:45 PM 10/23/2001, Perrin Harkins wrote: >Matt Sergeant wrote: > >>OK, so what are we missing? > > >Based on the comments I've seen here over the years, and some on Slashdot, >the thing that seems to worry people the most is the lack of an obvious >message queue API in Perl. I've seen plenty of implementations, but there >isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order. I think it's more than that. It's more of a general all around 'feeling' as I've said before. It's about people and it's about the standards. The thing about "Enterprise" applications is that there are many components to what "enterprise" means.... J2EE compromises a lot of standards and frameworks all in one and to read the books about them all would take several weeks at least. But at least I know that when I read a book on EJB, I know this is the plan and it's stable etc... whereas someone's particular idea of a transaction engine in Perl is just someone's idea of a transaction engine in Perl. It may be a good idea, but it's really quite scary to build a large system around something that may not have a lot of success stories around it. This is why Perrin's article is so good. Because it starts getting more high profile success stories out there. There really are otherwise not that many about Perl when compared to Java. And even then, let's also consider the programming base. When I advertise for Perl programmers, they generally just know how to do Web apps and it's pulling teeth to even get OO and Mod_perl capability. It has to be taught after such programmers are brought in. But with Java, it's quite rare to find a Java programmer that hasn't programmed at least their own minimal RMI server before. I have little doubt that this is because of the sheer amount of documentation for making an RMI server plus the fact that it is a true "standard" so people feel comfortable that it is supported in a large community. Remember that my email said, I "feel" better about coding middleware in Java than in Perl. Just as I "feel" better about coding front-end in Perl. This is a "feeling" and isn't necessarily something that can be quantified -- it is also about perception which is something that cannot be ignored. And part of it is about "soft" issues like knowing that I can find Java programmers at a dime a dozen who have done middleware coding before in Java. I think more success stories would help. I also think official endorsement by key members of the Perl community (eg Larry) would help certain projects. ie I believe SOAP::Lite is now the defacto standard SOAP Library for Perl that people would recommend anyone to use no? So why is it still SOAP::Lite and not moved and advocated into the SOAP namespace where it belongs and make it the defacto standard SOAP engine for Perl if it's proven itself? Of course, choice is part of what makes Perl fun. But fun isn't for everyone. eg when it comes to such niche libraries as middleware tools, it's not so fun to have choices if none of the choices are very easy to evaluate. It's much nicer for a programmer to be able to reliably choose a tool they feel is backed by a strong community beyond just the immediate few people who may have done X middleware for one project or group of projects for one company. I really would like to see a generally endorsed P2EE project which includes SOAP::Lite as an interoperable webservices engine, a messaging engine, and transaction engine. Authentication engine and Session engine would be quite useful to include as well. Oh and Moseley's (sp?) servlets in Perl project would be a cool one to include as well. That would make it compete pretty much head to head with J2EE. And then success stories on top of P2EE. === To: Leon Brocard <acme@astray.com>, modperl@apache.org From: Gunther Birznieks <gunther@extropia.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 23:36:31 +0800 At 10:36 PM 10/23/2001, Leon Brocard wrote: >Perrin Harkins sent the following bits through the ether: > > > Perhaps a port of JMS is in order. > >Interestingly, I've been thinking along the same lines. Spread >(http://www.spread.org/) can be used for the publish/subscribe >messaging domain but queueing seems to be important too. Straying a >bit offtopic perhaps, but I wonder what would be involved... One thing that would be interesting to me is an engine that can provide real time pricing feeds. It seems to me that jabber (chat engine) is actually a lot more powerful than being about chatting. Some applications are lonely and want instant messaging too. :) Queuing is important but for different reasons and usually different applications.... eg if your circuits are global. eg a London broker makes a transaction destined for Singapore, but has to go via Hong Kong and the London/HongKong circuit is only up every 5 minutes... Although this is not dissimilar to the resilience of a message delivered via SMTP relays. === To: mod_perl List <modperl@apache.org> From: Matthew Kennedy <mkennedy@opushealthcare.com> Subject: RE: Excellent article on Apache/mod_perl at eToys Date: 23 Oct 2001 10:49:25 -0500 On Mon, 2001-10-22 at 20:14, Robert Koberg wrote: > > For comparions, a nice aspect of j2ee applications IMHO is the > > "application server" tends to be more general. ie. the application > > server is not just the web server (as it is with mod_perl). I've found > > j2ee features such as message beans, queues and such especially useful > > for back-end work. For these reasons, I personally don't buy the > > argument that mod_perl makes an effective application server for a good > > sized task (your mileage will vary no doubt ;).> > What is stopping you from using both, if you want? Actually, I already do -- but not at the same time. The criteria I personally use is basically this: if the task doesn't involve more than one or two disparate system to be talked to, and a two tier model (apache and a rdbms for example) fits the problem well, then I'll chose Perl (mod_perl, Mason and *sometimes* ORBit's Perl bindings). If the app is to talk to a number of disparate systems and a variety of client types (stand alone app, web, wireless etc.) then generally I'll use the a J2EE app server etc. Of course there are will be exceptions. ORBit is a corba orb, BTW. === To: mod_perl List <modperl@apache.org> From: Matthew Kennedy <mkennedy@opushealthcare.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: 23 Oct 2001 11:00:12 -0500 On Mon, 2001-10-22 at 21:27, Perrin Harkins wrote: > It sounds like the limitation there is that you're > interfacing with systems that can't notify you when > something new happens. That's not Perl's fault. If you > wrote your daemons in Java alpahabet soup, they'd still > have to poll the pop3 server. Well, I'd more likely be using a standard javamail API within the context of a EJB server. There is a fairly rich set of call backs there which mean I generally don't have to poll/sleep etc. Also true of the java message service. === To: modperl@apache.org From: Nathan Torkington <gnat@oreilly.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 10:11:34 -0600 Leon Brocard writes: > > Perhaps a port of JMS is in order. > > Interestingly, I've been thinking along the same lines. Spread > (http://www.spread.org/) can be used for the publish/subscribe > messaging domain but queueing seems to be important too. Straying a > bit offtopic perhaps, but I wonder what would be involved... I like the idea of P2EE. If the goal is to provide the same features as Java, why not just implement the Java messaging, transactions, etc. APIs in Perl? That is, endeavour to have the same classes and methods as Java, to the greatest extent possible. That'll also make it possible for Java programmers to become Perl programmers, bwahaha. Someone described Java beans to me as being more or less "classes that follow conventions on things like accessor names and methods to respond to events. Those conventions permit introspection and interoperability between two classes that have no a priori knowledge of each other." I like that idea, too. It'd be fun to see what kinds of UI (both GUI and web) things become easier with this kind of functionality. Of course, we couldn't call it a Java bean. They'd have to be Camel droppings. :-) === To: Nathan Torkington <gnat@oreilly.com> From: Dave Rolsky <autarch@urth.org> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 12:02:00 -0500 (CDT) On Tue, 23 Oct 2001, Nathan Torkington wrote: > Of course, we couldn't call it a Java bean. They'd have to be Camel > droppings. :-) Perl Jewels (Joules?) -dave /*================== www.urth.org We await the New Sun ==================*/ === To: Gunther Birznieks <gunther@extropia.com>, Perrin Harkins <perrin@elem.com>, From: Stephen Adkins <stephen.adkins@officevision.com> Subject: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at Date: Tue, 23 Oct 2001 12:21:01 -0400 At 11:27 PM 10/23/2001 +0800, Gunther Birznieks wrote: >At 09:45 PM 10/23/2001, Perrin Harkins wrote: >>Matt Sergeant wrote: >>>OK, so what are we missing? ... >>Based on the comments I've seen here over the years, and some on Slashdot, >>the thing that seems to worry people the most is the lack of an obvious >>message queue API in Perl. I've seen plenty of implementations, but there >>isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order. ... >I really would like to see a generally endorsed P2EE project which includes >SOAP::Lite as an interoperable webservices engine, a messaging engine, and >transaction engine. Authentication engine and Session engine would be quite >useful to include as well. Oh and Moseley's (sp?) servlets in Perl project >would be a cool one to include as well. That would make it compete pretty >much head to head with J2EE. Hi, This issue of a P2EE specification has come up before (and I participated in the discussion), but since it is off-topic for the mod_perl list, I would appreciate some referrals of where to go to discuss this. Last time this came up, I was referred to three different mailing lists (also, see http://lists.perl.org/). However, none of the lists were interested in the P2EE problem (including the PerlSDK list). If no one suggests an appropriate list, I propose starting a "p2ee" group on SourceForge. This gives us mailing lists and a CVS repository for the artifacts of the effort (which will mostly be specifications and documentation, with maybe some Bundle files). I would also submit the list information to "perl.org" for inclusion in the list of lists. === To: modperl@apache.org From: Matthew Kennedy <mkennedy@opushealthcare.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: 23 Oct 2001 11:48:00 -0500 On Tue, 2001-10-23 at 10:09, Gunther Birznieks wrote: > At 08:46 PM 10/23/2001, Rob Nagler wrote: > >I don't quite understand the difference between worflow > >in the front-end and workflow in the back-end. They both > >change. The danger of making one part of the system > >easier to change is that people tend to "cheat". They > >won't put the business logic in the back-end if it takes > >twice as long. > Yes, people can cheat. But generally the workflow that is > most likely to change is the UI based workflow. UI isn't > just about templates, it's a lot about how you go from one > screen to the next, or not. > Actually business logic is a bit of a misnomer because > there is plenty of business logic in the front-end from > your choice of fields to the javascript to the UI > workflow. I agree. Basically there's front end business logic which defined the work flow of the client's end (web server/web browser etc). And then business logic in the middle tier. I've been using Apache/Jakarta Struts for the front end business stuff, a row of "session beans" (java speak for purely process related, not data related objects) behind the client to model work flow and then another row of "entity beans" (java speak for data object persistence) to get at a rdbms. This arrangement has worked well for me. This approach makes "cheating" code look immediately out-of-place, and just downright embarrassing :) Is there a Perl equivalent to Struts? Mason seems to come close if you keep yourself disciplined somewhat. === To: Nathan Torkington <gnat@oreilly.com>, modperl@apache.org From: Drew Taylor <drew@drewtaylor.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 13:10:14 -0400 At 10:11 AM 10/23/01 -0600, Nathan Torkington wrote: >Leon Brocard writes: > > > Perhaps a port of JMS is in order. > > > > Interestingly, I've been thinking along the same lines. Spread > > (http://www.spread.org/) can be used for the publish/subscribe > > messaging domain but queueing seems to be important too. Straying a > > bit offtopic perhaps, but I wonder what would be involved... > >I like the idea of P2EE. If the goal is to provide the same features >as Java, why not just implement the Java messaging, transactions, >etc. APIs in Perl? That is, endeavour to have the same classes and >methods as Java, to the greatest extent possible. That'll also make >it possible for Java programmers to become Perl programmers, bwahaha. The servlet API has been mostly(?) translated into perl by Brian Moseley. The homepage is http://libservlet.sourceforge.net/ and it's available on CPAN. The docs look a little parse at the moment, but kudos to Brian for the work done so far! Now if only I could figure out a good test application to try it with... === To: Matthew Kennedy <mkennedy@opushealthcare.com> From: Perrin Harkins <perrin@elem.com> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 13:15:53 -0400 Matthew Kennedy wrote: > On Mon, 2001-10-22 at 21:27, Perrin Harkins wrote: > >>It sounds like the limitation there is that you're interfacing with systems >>that can't notify you when something new happens. That's not Perl's fault. >>If you wrote your daemons in Java alpahabet soup, they'd still have to poll >>the pop3 server. >> > > Well, I'd more likely be using a standard javamail API within the > context of a EJB server. There is a fairly rich set of call backs there > which mean I generally don't have to poll/sleep etc. Also true of the > java message service. I suppose the Java stuff does make it more obvious how to do that kind of thing. There are dozens of ways to have some perl code execute every time a message arrives at a mail server without polling (Mail::Filter, procmail, Perl pop3 server, maybe PerlMX, etc.), but there isn't any One True Perl Mail API. Pointing newbies in the right direction is the strength of standardized APIs, and it does seem to have helped Java gain acceptance. There are commercial JMS implementations that simply poll database tables, but most people don't seem to mind as long as that's all hidden behind the standard JMS API. So, maybe a version in Perl would be a useful thing. === To: Stephen Adkins <stephen.adkins@officevision.com> From: Perrin Harkins <perrin@elem.com> Subject: Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 14:28:09 -0400 Stephen Adkins wrote: > If no one suggests an appropriate list, I propose starting a "p2ee" group Can I just say that P2EE is a horrible, horrible name? It includes the Java version number (when is J3EE coming out?), as well as Sun's desperate attempt to make it sound like something you buy ("Edition") rather than simply a collection of APIs. Something simple, like Perl Enterprise Project or Perl Enterprise APIs makes more sense to me. === To: "'Perrin Harkins'" <perrin@elem.com>, From: "Wilt, Paul" <pwilt@xanedu.com> Subject: RE: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at Date: Tue, 23 Oct 2001 15:03:44 -0400 PEP! (Perl Enterprise Project)! I like it! === To: Perrin Harkins <perrin@elem.com>, Nathan Torkington <gnat@oreilly.com> From: Stephen Adkins <stephen.adkins@officevision.com> Subject: Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl Date: Tue, 23 Oct 2001 15:38:17 -0400 At 02:28 PM 10/23/2001 -0400, Perrin Harkins wrote: >Stephen Adkins wrote: > >> If no one suggests an appropriate list, I propose starting a "p2ee" group > > >Can I just say that P2EE is a horrible, horrible name? It includes the >Java version number (when is J3EE coming out?), as well as Sun's >desperate attempt to make it sound like something you buy ("Edition") >rather than simply a collection of APIs. > >Something simple, like Perl Enterprise Project or Perl Enterprise APIs >makes more sense to me. Hi, Several of you have made the same good point. And now the naming flame war has already begun... ;-) Unless there is violent opposition, the name will be Perl Enterprise Framework I would rather name it after the outcome (Framework) than the process (Project). The mailing list will be perl-enterprise@perl.org (preferred) or pef@perl.org (in case Nathan already has it set up) If this seems reasonable, let's not flood the list with "ok with me" messages or "how about 'foo'?" messages. Stephen === To: modperl@apache.org From: Rob Nagler <nagler@bivio.net> Subject: Re: Excellent article on Apache/mod_perl at eToys Date: Tue, 23 Oct 2001 13:29:11 -0600 Gunther wrote: > If you do not have a strongly typed system, then when you break apart and > rebuild another part of the system, Perl may very well not complain when a > subtle bug comes up because of the fact that it is not strongly typed. > Whereas Java will complain quite often and usually early with compile time > checking. I don't think there's an "objective" view about this. I also think the "it compiles, so it works" attitude is dangerous. You don't know it works until your unit and acceptance tests pass. I've been in too many shops where the "nightly build" was the extent of the quality assurance program. > Compile time checking can definitely be a friend of yours especially when > dealing with large systems. But it's also a friend that's judgemental > (strongly typed) so he's a pain to drag along to a party.... To me, strongly vs weakly typed is less descriptive than statically vs dynamically typed. For example, Java is missing "undef". It has NULL for pointers, but not "undef" for ints, chars, booleans, etc. Large systems often have unexpected initialization order problems which are not handled well by Java due to this missing feature. > Java's support for multi-threading makes writing servers feel fairly > trivial with no jumping through IPC::Shared memory stuff hoops to get > shared memory caches and the like.. you just synchronize on global data > structures. It's important to define the problem space for this discussion. I think Perl is really good for information systems, be they enterprise or not. I probably wouldn't program a real-time system in Perl. I might program it in Java. Here's a strong statement: Threads have no place in information systems. The NYSE is run on Tandem boxes. Tandem's OS does not have threads. The NYSE can process over a billion stock transactions a day. The EJB spec says you can't fire off threads in a bean. I think there's a reason for the way these systems have been architected. Threads are a false economy for systems which have to scale. As some people have joked, Java is Sun's way of moving E10K servers. SMP doesn't scale. As soon as you outgrow your box, you are hosed. A shared memory cache doesn't work well over the wire. In my experience, the only way to build large scale systems is with stateless, single-threaded servers. === To: Tom Servo <tomservo@cnw.com> From: Emad Fanous <Emad_Fanous@citysearch.com> Subject: Re: [OT] excellent modperl/etoys article by Perrin revisited Date: Fri, 26 Oct 2001 08:04:07 -0700 Tom Servo wrote: > > I was told over the weekend by one of my old eToys cow-orkers that the > current incarnation of www.etoys.com isn't running our old code. Leave > it to KB to buy all the code then not bother to use it. > > I understand that's also the reason they couldn't be bothered to migrate > the old accounts over. www.etoys.com looks extremely similar to www.kbtoys.com. Whoever is interested, it looks like they are using unix on apache: Server: Apache/1.3.20 (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6b === To: "mod_perl List" <modperl@apache.org>, From: "Perrin Harkins" <perrin@elem.com> Subject: Re: [OT] excellent modperl/etoys article by Perrin revisited Date: Thu, 25 Oct 2001 14:54:54 -0400 > Perrin or others involved in the old eToys (or anyone in the new Toys) -- > does anyone know if this is the same mod_perl technology you guys wrote? I'm not involved in that anymore, so I don't have first-hand information. However, a brief look at the site makes me think they are not using any of what we wrote. The URL structures and query args (i.e. the public API of the site) are all very different. > I think it will make an interesting success story follow up if it is > successful because it would also show how easy it was for the intellectual > property written in mod_perl to be resold and reintegrated into another IT > infrastructure which would make VCs happy (ie they would think more about > being able to fund projects based on mod_perl if they know they could > always resell the IP). You have to remember that what we wrote was a specific application, not a generic store or application server. That code would only be useful if you wanted a store that did everything (data model, navigation, order processing) exactly the way we did. I very much doubt KB is that similar. Also, the documentation was great for an in-house project but not enough for a packaged commercial app. There was a basic shared knowledge assumed in most of it about the business goals and environment. Keep in mind that we wrote very little infrastructure code - no more than I would expect a J2EE project this large to write. The infrastructure came from CPAN, Apache, etc. and is known to be very portable. I suspect that KB has a team who supports their site and they chose to use the technologies they already have in place. People hate change, and looking at a foreign codebase, possibly in a language you don't know, is daunting. It would be the same thing if someone walked into an ASP shop with a bundle of WebLogic code and said "make it run, and work with our legacy systems, with these changes, by Christmas. And don't stop supporting our regular site. Oh, and we didn't hire any of the developers who wrote it or the business people who told them what to write, so you'll just have to read the source if you have questions that aren't in the documentation." Doesn't sound that appealing, does it? === To: Gunther Birznieks <gunther@extropia.com>, From: Drew Taylor <drew@drewtaylor.com> Subject: Re: [OT] excellent modperl/etoys article by Perrin revisited Date: Thu, 25 Oct 2001 14:22:22 -0400 At 12:26 PM 10/25/2001 +0800, Gunther Birznieks wrote: >I saw an article in today's ComputerWorld that indicates the technology et >al for eToys was bought by another toy firm (KB) and they plan to put it >up to sell toys for this holiday season again. > >http://www.computerworld.com/cwi/story/0,1199,NAV47_STO65008,00.html > >Perrin or others involved in the old eToys (or anyone in the new >eToys) -- does anyone know if this is the same mod_perl technology you >guys wrote? Well, I'm just talking off the top of my head, but my interpretation is that "the Web site relies on eToys software purchased at the bankruptcy auction and on KB Toys' existing IT infrastructure" means that it's the software Perrin et al. wrote, running on KB's hardware. I can't imagine that to mean that they rewrote the software. If so, that just validates the decisions the eToys design team made. Even more kudos Perrin! :-) === To: Gunther Birznieks <gunther@extropia.com> From: Tom Servo <tomservo@cnw.com> Subject: Re: [OT] excellent modperl/etoys article by Perrin revisited Date: Thu, 25 Oct 2001 10:57:20 -0700 (PDT) I was told over the weekend by one of my old eToys cow-orkers that the current incarnation of www.etoys.com isn't running our old code. Leave it to KB to buy all the code then not bother to use it. I understand that's also the reason they couldn't be bothered to migrate the old accounts over. ===