modperl-etoy_article_addendum

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.

===


the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu