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
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
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/
On Tue, Oct 23, 2001 at 12:02:00PM -0500, Dave Rolsky wrote:
Perl Jewels (Joules?)
Perl Oysters :-)
A
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
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/
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-- [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?
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,
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
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
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
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
==*/
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
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
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.
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
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
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.
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
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.
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
-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
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
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
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
: [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
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
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,
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.
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
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
45 matches
Mail list logo
