> 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
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. Where
On Tue, Oct 23, 2001 at 12:02:00PM -0500, Dave Rolsky wrote:
> Perl Jewels (Joules?)
Perl Oysters :-)
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/ !t
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
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://jav
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
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
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
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"
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 earl
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 im
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 sti
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 b
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
==*/
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
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 wonde
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
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 mes
-- [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 a
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 qu
>
> 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 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 plen
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
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 off
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
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
>
> 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
> 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 u
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 bean
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
> 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 w
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
> 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 th
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
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.
>
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, Ada
> 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 e
olkit 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 proje
>
> 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 any
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 y
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
> -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
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
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.
>
45 matches
Mail list logo
