Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
One important thing THERE IS ALREADY A P5EE MAILING LIST GUYS!! :) So basically if you want to add your feedback, go there! It's already done but it's not too late to add feedback. :) email ... [EMAIL PROTECTED] At 08:36 AM 10/29/2001, Medi Montaseri wrote: Similarly, this concept of Enterprise is a bugus idea ... from a pure computer science point of view, there is no such thing as an Enterprise. This is all Microsoft's branding trying to associate themselves with something big, and Sun is stupidly following it A pure computer science point of view... Well, very few things exist from a pure computer science point of view because it's based on low level algorithms typically. However, that does not mean models that encapsulate the complexity of all the algorithms put together in certain ways do not have or add value. The concept of the enterprise is a very real model of interpreting the world of IT and how to distinguish between a localized, single-protocol systems and an enterprise system. Enterprise being a Microsoft Branding term? I don't think believe that it came before Sun. Sun and Microsoft are not branding themselves the same way. And I believe that the term enterprise has been around for quite some years independent of Microsoft. However, because of the Java and Sun branding of J2EE, it is important that Perl and other languages come together to say how they fit the enterprise as well. Why is this important? Credibility. While it's true that many businesses do not require enterprise solutions, a business can feel more comfortable adopting a solution if they know that it can grow with them. For example, if I were to download a public domain web store, I would much prefer knowing that the ecommerce solution were used by Amazon.com because then I'd know that if my ReeferOnline store were to take off in Columbia, that it would scale and I wouldn't have to look for an alternative solution. Also, the fact that a larger corporation can use the application means that they've worked out security and other issues better than I, a small IT arm of a huge Drug Overlord, can afford the time and effort to check out. While not everyone may need these additional reassurances from a marketing point of view, the majority of the world does. My vote is to come up with something more pure than trendy like Enterprise. My vote is that anyone who doesn't like a name should be the first person to come up with an alternative idea rather than just negating it and asking for others to come up with the hard work of coming up with something different. :) Anyway, please do visit the P5EE list. There is also an archive of past posts so you can play catch up from the last week. http://archive.develooper.com/p5ee%40perl.org/
Re: Excellent article on Apache/mod_perl at eToys
Rob Nagler [EMAIL PROTECTED] writes: 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. Exactly- the statically typed languages I am familiar with have a casting mechanism to utterly subvert compile-time type checks. While static typing allows better compile-time optimization, it's value as a debugging mechanism is near the bottom of the list of advantages for engineering a large project. If interface guarantees are important between Perl objects, I'd have a look at Class::Contract. 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. To me, it is utterly nondescriptive in a PHB buzzwordy way, whereas static vs. dynamic typing is meaningful (and what I think most people really mean by the former). [...] 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. ^^ Could you say some more about what you mean by this? Do you mean something like use a functional language (like Haskell or Scheme), rather than an imperative language (like C, Java, Perl ...), or are you talking more about the application's platform and design (e.g. http://www.kegel.com/c10k.html )? -- Joe Schaefer
Re: Excellent article on Apache/mod_perl at eToys
Exactly- the statically typed languages I am familiar with have a casting mechanism to utterly subvert compile-time type checks. While static typing allows better compile-time optimization, it's value as a debugging mechanism is near the bottom of the list of advantages for engineering a large project. If interface guarantees are important between Perl objects, I'd have a look at Class::Contract. One nice thing about which is that the contract portion can be essentially turned off in production. Gives you the best of both worlds: strong checking during development w/ good speed in productin. 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. To me, it is utterly nondescriptive in a PHB buzzwordy way, whereas static vs. dynamic typing is meaningful (and what I think most people really mean by the former). Comparing Perl to other OO languages runs into the fact that only Perl uses a fairly high-level object as its basic storage unit (scalar). The first thing most people write/buy for the strongly typed languages is a library of contaner classes: things that subvert the strong checking of low-level types. The second thing that usually happens is that the low-level types get their base operations overloaded via container objects. Net result is minimal -- at best -- type checking. The problem isn't really that scalars are weakly typed, since all you can deal with are scalars. If programmers bothered to write checks in their code (e.g., $foo =~ /^\d$/ or croak NAN) then Perl will do as well or better than most languages. Coders are too used to having the low-level type checking around as a crutch, so they don't. Implementing code that uses Class::Contract forces you to declare [perhaps even analyze?] not only data types but expectations, and ends up causing people to do a much better job of checking then most other languages even allow. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
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. 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). PEP is a much better acronym though. No more Java beans: use PEP pills!
Re: Excellent article on Apache/mod_perl at eToys
On 22 Oct 2001, Matthew Kennedy wrote: Why was Berkeley DB chosen for caching when a RDBMS (mysql in this case) was already being used? For speed. You want to hit the RDBMS as little as possibly; Berkeley DB makes a good cache. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: Excellent article on Apache/mod_perl at eToys
On Tue, Oct 23, 2001 at 12:02:00PM -0500, Dave Rolsky wrote: Perl Jewels (Joules?) Perl Oysters :-) A
Re: Excellent article on Apache/mod_perl at eToys
On Thu, 18 Oct 2001 19:11:04 -0700 (PDT) Andrew Ho [EMAIL PROTECTED] wrote: 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 I've translated this article into Japanese, and you can get it on http://bulknews.net/lib/doc-ja/etoys.ja.html http://bulknews.net/lib/doc-ja/etoys.ja.pod Just wanted to let you know. Thanks for the excellent article, Perrin! -- Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: Excellent article on Apache/mod_perl at eToys
On Tue, 2001-10-23 at 12:31, Dave Hodgkinson wrote: Nathan Torkington [EMAIL PROTECTED] writes: Is there a nice graphicy map of what actually constitutes J2EE onto which we can overlay the relevant perl bitz? Something like this: http://www.onjava.com/pub/a/onjava/api_map/ http://java.sun.com/j2ee/ I wonder if such a P2EE project should build on CORBA just as J2EE does? Is interoperability with J2EE a goal? The other approach is to get the Perl language ported to the JVM. I know some work has been put into that. In this case it's important to be able to access the Java API's as easily as it is in Java. I lean toward the second approach since it would give P2EE a faster start, building on already existent frameworks. Eg. you could begin writing EJB components in perl immediately. Matt -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
Re: Excellent article on Apache/mod_perl at eToys
I suppose I should point out that perl.com is always interested in mod_perl articles. If you've learned lessons that others could benefit from, contact the perl.com editor, Simon Cozens [EMAIL PROTECTED]. Nat
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
[EMAIL PROTECTED] wrote: I'm surprised that no one has, jokingly, suggested PEE. Sorry, couldn't resist. :) Neither could these people: http://pee.sourceforge.net/
Re: Excellent article on Apache/mod_perl at eToys
Nathan Torkington wrote: I like the idea of P2EE. Yeah. Maybe it will take off better than Pervlets did. Mike808/ -- perl -le $_='7284254074:0930970:H4012816';tr[0-][ BOPEN!SMUT];print
Re: Excellent article on Apache/mod_perl at eToys
Matthew Kennedy wrote Is there a Perl equivalent to Struts? Mason seems to come close if you keep yourself disciplined somewhat. I mentioned a couple of tools in the article that are specifically aimed at MVC: OpenInteract, and Apache::PageKit. Actually, I think it's pretty easy to replace Struts. Think about what it offers. First, there's a set of taglibs for writing templates without embedding Java code. Template Toolkit blows it away in this area. (I once suggested to one of the authors of Struts that tags like logic:greaterThan parameter=number value=7 are a bit verbose. He told me to buy DreamWeaver.) It doesn't add much beyond advice in the model area. The controller is basically just a dispatch table which can easily be replaced with Apache::Dispatch or even a well-written httpd.conf. To be fair, it does some things to try and make forms easier to deal with. You'd need to get OpenInteract or PageKit to replace that stuff, or write some glue code for the form validators and such on CPAN. Of course you could use Mason, but most Mason users aren't aiming for a strict MVC separation and it's very easy to cheat when your templates are written in in-line perl. - Perrin
Re: [OT] Perl daemons (was Re: Excellent article on Apache/mod_perl at eToys)
Matthew Kennedy [EMAIL PROTECTED] wrote: 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. [ ... ] Is anyone else using independent perl processes in a web app, or have strong reasons not to? I'm using a whole host of perl cron jobs to do deferred processing (take stuff out of a queue and handle it, the queue usually being a table on a RDBMS), as well as assorted indexation and cleanup tasks. In fact, pretty much every new project that I work on ends up generating: * perl modules * html and templates * database tables, and * cron jobs Isn't that what everyone else does? I don't exactly see this as a dirty secret either... I've also done perl daemons that were meant to run permanently, but there isn't so often the need for that. -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
RE: Excellent article on Apache/mod_perl at eToys
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. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
RE: Excellent article on Apache/mod_perl at eToys
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. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
Re: Excellent article on Apache/mod_perl at eToys
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. 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
Re: Excellent article on Apache/mod_perl at eToys
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?
Re: Excellent article on Apache/mod_perl at eToys
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. - Perrin
Re: Excellent article on Apache/mod_perl at eToys
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... Leon -- Leon Brocard.http://www.astray.com/ Nanoware...http://www.nanoware.org/ ... Byte this (designer underware)
Re: Excellent article on Apache/mod_perl at eToys
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. Later, Gunther
Re: Excellent article on Apache/mod_perl at eToys
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. Later, Gunther
[OT] Perl daemons (was Re: Excellent article on Apache/mod_perl at eToys)
Is anyone else using independent perl processes in a web app, or have strong reasons not to? Our web application (Metadot) provides a number of functions that are fulfilled by a daemon written in perl. Among these are: collecting content from syndicated news channels, sending email messages to users about newly added content, retrieving email messages to add to site content, monitoring and cleaning database tables, etc. We run this daemon as a cron job every twenty minutes, and within it we have sections for tasks that are performed at hourly, daily and weekly intervals. The script is a bit messy but could still serve as a skeleton for similar ones for other applications. It's called metadotd.pl and is part of our open source distribution available from Metadot.net. Regards, Claudio
Re: Excellent article on Apache/mod_perl at eToys
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.
Re: [OT] Perl daemons (was Re: Excellent article on Apache/mod_perl at eToys)
-- [EMAIL PROTECTED] on 10/23/01 10:23:18 -0500 Is anyone else using independent perl processes in a web app, or have strong reasons not to? I use them for quite a few things. fork/exec works nicely in perl (on unix at least), allows me to write daemons for most things. Why do you ask? sl
RE: Excellent article on Apache/mod_perl at eToys
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. Matt -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
Re: Excellent article on Apache/mod_perl at eToys
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. -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
Re: Excellent article on Apache/mod_perl at eToys
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. :-) Nat
[OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
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. Stephen
Re: Excellent article on Apache/mod_perl at eToys
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. -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
Re: Excellent article on Apache/mod_perl at eToys
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 ==*/
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Stephen Adkins writes: 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. We'd be glad to host it at perl.org. If that's cool with you, I'll ask Ask to create the mailing list and CVS repository on perl.org. Once we have something to show, we can get a website too. I'd imagine the CVS would include code we write, snapshots of which would be periodically released to CPAN. Anyway, that's for the list once we have it. Nat
Re: Excellent article on Apache/mod_perl at eToys
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... Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** ICQ: 135298242
Re: Excellent article on Apache/mod_perl at eToys
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. - Perrin
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
On Tuesday 23 October 2001 18:21, Stephen Adkins wrote: 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. 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. FWIW, (given the fact that we're talking about talking about it, I guess it's the moment for more-or-less useless ideas) I'd prefer it not to be called p2ee. It sounds more like a copy thing, and copies aren't good. What about EnterPerl or something like that ? In any case, please create the specific list before we start discussing the name here ;-) -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Prediction is very difficult, especially of the future. -- Niels Bohr
Re: Excellent article on Apache/mod_perl at eToys
Nathan Torkington [EMAIL PROTECTED] writes: 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. That's P5EE Is there a nice graphicy map of what actually constitutes J2EE onto which we can overlay the relevant perl bitz? -- David Hodgkinson, Wizard for Hirehttp://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com All the Purple Family Tree news http://www.slashrock.com Interim Technical Director, Web Architecture Consultant for hire
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Nathan, At 11:06 AM 10/23/2001 -0600, Nathan Torkington wrote: Stephen Adkins writes: 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. We'd be glad to host it at perl.org. If that's cool with you, I'll ask Ask to create the mailing list and CVS repository on perl.org. Once we have something to show, we can get a website too. I'd imagine the CVS would include code we write, snapshots of which would be periodically released to CPAN. Anyway, that's for the list once we have it. Nat That would be great (as long as perl.org can host the CVS too). My concern was that perl.org might not be as specialized in hosting development teams as sourceforge.net. Do you support viewcvs or similar for web browsing of the CVS repository? Stephen
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Stephen Adkins writes: That would be great (as long as perl.org can host the CVS too). My concern was that perl.org might not be as specialized in hosting development teams as sourceforge.net. Do you support viewcvs or similar for web browsing of the CVS repository? cvsweb. You can see what we've got at cvs.perl.org. I'll ask Ask to add the list and repository. Cheers; Nat
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
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. - Perrin
RE: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
PEP! (Perl Enterprise Project)! I like it! Paul E Wilt Principal Software Engineer XanEdu, Inc. (division of Proquest Information and Learning) http://www.xanedu.com mailto:[EMAIL PROTECTED] 300 North Zeeb Rd Phone: (734) 302-6545 (800) 218-5971 x6545 Ann Arbor, MI 48106Fax: (734) 975-6440 -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 23, 2001 2:28 PM To: Stephen Adkins Cc: mod_perl List Subject: Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys 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. - Perrin
Re: Excellent article on Apache/mod_perl at eToys
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. Rob
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
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 [EMAIL PROTECTED] (preferred) or [EMAIL PROTECTED] (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
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 3:38 PM -0400 10/23/01, Stephen Adkins wrote: Several of you have made the same good point. And now the naming flame war has already begun... ;-) This is a discussion. Something has been proposed and it needs a name. I'd hardly call this a flame war. A name is pretty important and if it's acronym isn't easily recognized, it isn't going to gain the support of developers. J2EE is catchy, so we need something catchy. PEF isn't nearly as catchy as P2EE or P5EE or PEA (Perl Enterprise API), but maybe I'm just crazy. Rob -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Robert Landrum [EMAIL PROTECTED] wrote: ... A name is pretty important and if it's acronym isn't easily recognized, it isn't going to gain the support of developers. J2EE is catchy, so we need something catchy. PEF isn't nearly as catchy as P2EE or P5EE or PEA (Perl Enterprise API), but maybe I'm just crazy. howsabout: p5ice ? Perl 5 Integrated Classes for the Enterprise or mebbe: Interface Client for Enterprises possibly: Insane Community of Entrepeneurs or even: Icky Commercialized Edition i can already see all the cool Ice-ey perl logos with icicles hanging from their frosted fonts :-) -dave
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
I'm surprised that no one has, jokingly, suggested PEE. Sorry, couldn't resist. :) -- === If you put three drops of poison into a 100 percent pure Java, you get - Windows. If you put a few drops of Java into Windows, you still have Windows. -- Sun Microsystems CEO, Scott McNealy __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 03:38 AM 10/24/2001, Stephen Adkins wrote: 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 [EMAIL PROTECTED] (preferred) or [EMAIL PROTECTED] (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 I think this name and mailing list is excellent and much better than P2EE. The mere fact that there is an endorsed perl.org mailing list for people who wish to ask about enterprise issues (even without a specific standard) is a huge step further in terms of making people aware that Perl CAN BE used for the enterprise. That is, there is a definite perception difference between [EMAIL PROTECTED] and [EMAIL PROTECTED] [EMAIL PROTECTED] has a perception of being endorsed as a place for a standard rather than just a single couple of people's ideas on sourceforge.com (of which there are thousands) and is likely to get more attention.
Re: Excellent article on Apache/mod_perl at eToys
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, Matt On Thu, 2001-10-18 at 21:11, 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 Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 -- -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
RE: Excellent article on Apache/mod_perl at eToys
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?
Re: Excellent article on Apache/mod_perl at eToys
on 10/22/01 11:13 AM, Matthew Kennedy at [EMAIL PROTECTED] 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. - Perrin
Re: Excellent article on Apache/mod_perl at eToys
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 Yup, this is an excellent read. Thanks Perrin. Greg
Re: Excellent article on Apache/mod_perl at eToys
Yeah we really enjoyed it over here. I think it's really excellent to get great advocacy articles about Perl and surrounding products (mod_perl, TT, etc) powering real businesses with real high powered needs out there like this one. :) At 04:40 PM 10/19/2001, Greg Cope wrote: 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 Yup, this is an excellent read. Thanks Perrin. Greg __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
RE: Excellent article on Apache/mod_perl at eToys
-Original Message- From: Gunther Birznieks [mailto:[EMAIL PROTECTED]] Sent: Friday, October 19, 2001 6:47 AM To: mod_perl List Cc: Template Toolkit List Subject: Re: Excellent article on Apache/mod_perl at eToys Yeah we really enjoyed it over here. I think it's really excellent to get great advocacy articles about Perl and surrounding products (mod_perl, TT, etc) powering real businesses with real high powered needs out there like this one. :) I particularly like the part about sending a router up in flames. That came across a little better at ApacheCon - maybe the article needs some flaming icon or something ;) nice work Perrin (as usual) --Geoff
Re: Excellent article on Apache/mod_perl at eToys
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. - Perrin
Re: [Templates] Re: Excellent article on Apache/mod_perl at eToys
What I found most interesting was the detail of the extensive caching which was implemented to survive the seasonal rush. I look forward to working on a project one day that is big enough to warrant such a system. All in all, a most excellent and informative read. Thanks again for everything you've personally done for the community! I look forward to seeing those graphics. :-) At 09:49 AM 10/19/01 -0400, Perrin Harkins wrote: 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. Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** ICQ: 135298242
RE: Excellent article on Apache/mod_perl at eToys
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. Hi Perrin 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. thanks Clinton Gormley
RE: [Templates] Re: Excellent article on Apache/mod_perl at eToys
I work in a predominately M$ shop. AS a matter of fact, I am one of only two Perl/mod_perl programmers in a development department with 25 other programmers. Sometimes it feels like we are working in a vacuum. This list and articles like the eToys article along with the overwhelmingly superior performance of mod_perl/Apache vs. either M$ IIS/ASP or M$ IIS/ColdFusion are what make, at least for me, doing what I do for a living where I do it possible. If it weren't for our success with mod_perl/Apache I really believe that this project would have been converted to ColdFusion a long time ago. Anecdotal evidence like the eToys article only add to the growing body of evidence that what we do with mod_perl is really the best of the available alternatives. Not only doe Perrin deserve a pat on the back for his article, but everyone who promotes the use of these technologies should feel good about what themselves. --Joe Breeden --- If it compiles - Ship It! -Original Message- From: Drew Taylor [mailto:[EMAIL PROTECTED]] Sent: Friday, October 19, 2001 8:59 AM To: Perrin Harkins; mod_perl List Cc: Template Toolkit List Subject: Re: [Templates] Re: Excellent article on Apache/mod_perl at eToys What I found most interesting was the detail of the extensive caching which was implemented to survive the seasonal rush. I look forward to working on a project one day that is big enough to warrant such a system. All in all, a most excellent and informative read. Thanks again for everything you've personally done for the community! I look forward to seeing those graphics. :-) At 09:49 AM 10/19/01 -0400, Perrin Harkins wrote: 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. Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** ICQ: 135298242
Re: Excellent article on Apache/mod_perl at eToys
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
Re: Excellent article on Apache/mod_perl at eToys
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. Brian Nilsen [EMAIL PROTECTED] On Fri, 19 Oct 2001, Perrin Harkins wrote: 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
Re: Excellent article on Apache/mod_perl at eToys
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?
[OT] Re: Excellent article on Apache/mod_perl at eToys
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 -- D_OMM O_xyderkes M_echanenhttp://domm.zsi.at M_asteuei
Re: [OT] Re: Excellent article on Apache/mod_perl at eToys
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. - Perrin
Re: [OT] Excellent article on Apache/mod_perl at eToys
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.
Excellent article on Apache/mod_perl at eToys
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 Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
