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
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
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
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
[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/
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
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
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
==*/
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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.
62 matches
Mail list logo
