This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: RE: mod_perl advocacy project resurrection
From: brian moseley <bcm@maz.org>
Date: Tue, 5 Dec 2000 12:22:04 -0800 (PST)
On Tue, 5 Dec 2000, Stas Bekman wrote:
> Therefore if the same job can be done with Perl and
> Java, why not to have your staff happy? That's the main
> point I think.
>
> Of course if the bussiness suffers because Perl is not
> good enough, that's a different point. Given that at
> least the same could be done with Perl and Java, Perl
> and PHP, Perl and whatever, I want to code in Perl.
exactly my point. and in my experience as well as that of
many folks i've spoken with, it's just not the case.
take CPTH web mail. we used Mail::Folder and MIME::*, but we
had to write our own custom subclasses of all of them to
deal with our mail store, with folder sorting, with mime
tree caching, etc. and now that we're moving to an IMAP
backend, we have to write a whole new custom set of
subclasses based on Mail::IMAPClient.
if we'd have been operating in a java environment, we'd have
been able to take advantage of the "insanely great"
JavaMail, which comes out of the box with an IMAP backend. a
prototype IMAP re-implementation of our mail client took
about 3 days, as opposed to the month or more it will take
us to do the perl implementation.
the availability of application server products in the java
world is another example. go look at enhydra enterprise
(http://www.enhydra.org/software/enhydraEnterprise/) and
tell me that something like that exists in the perl world.
and there are many products like this, both commercial and
open source. competition flourishes, and the industry
benefits. there are lots of folks on the market with
experience developing for and operating weblogic. it's
easier to hire and you get better time to market. you don't
have to spend time re-integrating Apache::Session and
Apache::DBI and Apache::WipeMyAss with each new project.
this is why i think AO is some important, altho its scale is
much smaller. it's a first step towards something like
enhydra enterprise for those of us who would, all other
things being equal, prefer to use perl.
> Therefore, we should make converts and when more people
> will prefer coding in Perl, because they *love* it and
> it's a legitimate choice, there won't be a question of
> whether I can afford doing this project in mod_perl,
> because there will be enough mod_perl programmers to
> take over it.
>
> So to answer your question, the complelling reason is
> joy and satisfaction. Given that other factors are at
> least compatible.
yes, but we have to get to that point, and we're not there.
===
Subject: Re: [OT] mod_perl longevity [Was: mod_perl advocacy project
From: brian moseley <bcm@maz.org>
Date: Tue, 5 Dec 2000 12:28:08 -0800 (PST)
On Tue, 5 Dec 2000, Ajit Deshpande wrote:
> Well, the above question pre-supposes that Java is
> inherently *better* than mod_perl for some definition of
> "better".
it's true. i stayed away from defining better in that msg,
but explored in a separate one in this thread. suffice to
say, the wealth of existing standards-based components, the
focus on creating a platform for enterprise applications,
and the competitive vendor landscape for development tools
and infrastructure components, all of help define "better"
imo.
===
Subject: Re: mod_perl advocacy project resurrection
From: mkennedy@hssinc.com (Matthew Kennedy)
Date: Tue, 05 Dec 2000 14:57:18 -0600
Thomas J. Mather" wrote:
>
> On Tue, 5 Dec 2000, Michael Nachbaur wrote:
>
> > I don't know what I'm getting at here, but I see that Perl is half a
> > step behind Java in many ways, except for the performance issues
> > (which perl is leagues ahead). For my company, we're probably going
> > Java, but it sorta makes sense for us (we need an enterprise solution
> > now...not when the Perl community gets around to it).
Server side performance of Java shouldn't be an issue for you.
>
> How exactly does Java provide a better "enterprise solution" than
> Perl? And how can the Perl community better provide an "enterprise
> solution"?
I've worked with both (Java 2 EE and tools like Apache::ASP/Mason). What
people want out of an "enterprise solution" is a middle tier which is
not tied into the presentation. When you free your process decisions
from the presentation in that way, you can implement a B2B type
transactions much more easily. The rationale for J2EE is already defined
quite well in this way.
<snip>
> I guess what I'm getting at is that I hear a lot of marketing hype about
> Java being a better "enterprise solution", but I'm curious as to what are
> the purely technical reasons for using Java over Perl. What exactly can
> you do in Java that you can't do as easily in Perl?
Transaction support for your business logic is easy in J2EE. It's not
clear how you do this in Perl? By CORBA ORBs and TMs I suspect, but
there's no real standard framework for that in Perl. There are other
lesser advantages too... standardized XML support is one of them
(topical for me right now).
===
Subject: Re: mod_perl advocacy project resurrection
From: Drew Taylor <drew@openair.com>
Date: Tue, 05 Dec 2000 16:10:01 -0500
Stas Bekman wrote:
>
> On Tue, 5 Dec 2000, brian moseley wrote:
>
> >
> > people won't use the software if you don't give them a
> > compelling reason. mod_perl and the higher layer systems
> > that use it are not as easy to configure or program as php,
> > and they have a lot less support from external software
> > vendors or relevance inside engineering shops than java. we
> > are being squeezed from both ends.
> >
> > i had lunch with doug and jon swartz not too long ago,
> > talking about the possibility of starting a web application
> > infrastructure company based on mod_perl and mason. when we
> > got down to it, the fundamental question was: why not just
> > use java? and we couldn't find any answer other than "i like
> > perl better". and that's not a reasonable business
> > justification.
> >
> > at some point we're going to run out of hobbyists and others
> > who /can/ justify using mod_perl-based technologies because
> > they like perl better.
>
> You forget about satisfaction. Do you feel happier to program in Java than
> Perl? You want your employees to enjoy they work. We spend too much time
> working, I want to enjoy most of my working hours. You want me for my
> design and architecture skills, you have to give me something in return.
> For me salary is much less important factor than satisfaction.
>
> Therefore if the same job can be done with Perl and Java, why not to have
> your staff happy? That's the main point I think.
>
> Of course if the bussiness suffers because Perl is not good enough, that's
> a different point. Given that at least the same could be done with Perl
> and Java, Perl and PHP, Perl and whatever, I want to code in Perl.
I know this goes a little off topic, so I apologize in advance.
One big sticking point with Perl I'm just starting to run into is XML.
Yes, Perl has great XML modules, and many more promising ones. But where
is the _validating_ XML parser? I'm doing some XML work where a
validating parser would be very nice, speed hit or not. I can work
around it easily (this is perl :-), but it would save me some work.
The XML & Java combination has a LOT more corporate resources (read $$$)
focused on it than Perl & XML. How many Java-based XML software
announcements have you seen lately? Now compare that to Perl-based XML
modules. The numbers don't compare very well. What can we do about this?
I can't help write a validating parser, but I would be happy to help
test it out. IMHO, more XML support would help sell perl into more
corporate settings. Java is big into buzzwords, and XML is one of the
biggest there is at the moment. And as we know PHBs like buzzwords, so
that is one more point in Java's favor.
I'm quite happy being a perl programmer, although I do plan on learning
other languages in the future. I love perl. As such, I'm definately all
for keeping my future job market as large as possible. If getting perl
more into the corporate eye helps that goal, then what do I need to do
as a "little guy"?
===
Subject: RE: mod_perl advocacy project resurrection
From: Matt Sergeant <matt@sergeant.org>
Date: Tue, 5 Dec 2000 21:11:22 +0000 (GMT)
On Tue, 5 Dec 2000, brian moseley wrote:
> the availability of application server products in the java
> world is another example. go look at enhydra enterprise
> (http://www.enhydra.org/software/enhydraEnterprise/) and
> tell me that something like that exists in the perl world.
http://www.mediasurface.com
Sadly though, its only one product in a sea of Java products.
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Subject: RE: mod_perl advocacy project resurrection---------------------------------------------------------------------
From: Matt Sergeant <matt@sergeant.org>
Date: Tue, 5 Dec 2000 21:11:22 +0000 (GMT)
On Tue, 5 Dec 2000, brian moseley wrote:
> the availability of application server products in the java
> world is another example. go look at enhydra enterprise
> (http://www.enhydra.org/software/enhydraEnterprise/) and
> tell me that something like that exists in the perl world.
http://www.mediasurface.com
Sadly though, its only one product in a sea of Java products.
===
Subject: Re: mod_perl advocacy project resurrection
From: Ben Cottrell <benco@stockmaster.com>
Date: Tue, 05 Dec 2000 16:58:56 -0500
On Tue, 5 Dec 2000 12:40:47 -0800 (PST), brian moseley wrote:
> On Tue, 5 Dec 2000, Dave Rolsky wrote:
>
> > Each has its advantages. Perl is good for real
> > programmers who are going to write code to actually
> > solve a problem. Java is good for monkeys who think
> > that buying a $100k app server and tweaking it via a
> > monolithic API will give them what they want.
>
> c'mon dude, offer something constructive to the thread or
> stay out of it.
Except that he's absolutely right.
I have personal experience -- my company is ripping out its elegant
mod_perl based architecture and replacing it with *cough* the
j-word *cough*.
mod_perl is the superior technology, hands down. This is coming from
someone who's an avowed perl hater, too. I loathe perl itself, but
have to admit that mod_perl, when you compare it to the alternatives
in the dynamic-web-content space, just plain rules.
Just one example... my company ran into a bug in mod_perl a while ago...
so what did we do? we fixed it, and submitted a patch. If we'd been
using the J-word, we'd have been stuck. Tell me one big-name app server
that's written in C and that'll let you download the source and fix
bugs.
===
Subject: RE: mod_perl advocacy project resurrection
From: brian moseley <bcm@maz.org>
Date: Tue, 5 Dec 2000 14:24:23 -0800 (PST)
On Tue, 5 Dec 2000, Matt Sergeant wrote:
> On Tue, 5 Dec 2000, brian moseley wrote:
>
> > the availability of application server products in the java
> > world is another example. go look at enhydra enterprise
> > (http://www.enhydra.org/software/enhydraEnterprise/) and
> > tell me that something like that exists in the perl world.
>
> http://www.mediasurface.com
>
> Sadly though, its only one product in a sea of Java
> products.
doesn't look like enhydra enterprise at all. i'm not talking
about a content management system, i'm talking about a
scalable middle tier service upon which any type of
application can be built.
===
Subject: Re: mod_perl advocacy project resurrection
From: Perrin Harkins <perrin@primenet.com>
Date: Tue, 5 Dec 2000 14:46:58 -0800 (PST)
On Tue, 5 Dec 2000, Matthew Kennedy wrote:
> I've worked with both (Java 2 EE and tools like Apache::ASP/Mason).
> What people want out of an "enterprise solution" is a middle tier
> which is not tied into the presentation. When you free your process
> decisions from the presentation in that way, you can implement a B2B
> type transactions much more easily. The rationale for J2EE is already
> defined quite well in this way.
Mr. Mather's Apache::PageKit module does a good job of implementing the
model/view/controller paradigm in mod_perl.
> Transaction support for your business logic is easy in J2EE. It's not
> clear how you do this in Perl?
Use an RDBMS.
===
Subject: Re: mod_perl advocacy project resurrection
From: mkennedy@hssinc.com (Matthew Kennedy)
Date: Tue, 05 Dec 2000 17:12:35 -0600
Perrin Harkins wrote:
>
> On Tue, 5 Dec 2000, Matthew Kennedy wrote:
> > I've worked with both (Java 2 EE and tools like Apache::ASP/Mason).
> > What people want out of an "enterprise solution" is a middle tier
> > which is not tied into the presentation. When you free your process
> > decisions from the presentation in that way, you can implement a B2B
> > type transactions much more easily. The rationale for J2EE is already
> > defined quite well in this way.
>
> Mr. Mather's Apache::PageKit module does a good job of implementing the
> model/view/controller paradigm in mod_perl.
I will check that out.
> > Transaction support for your business logic is easy in J2EE. It's not
> > clear how you do this in Perl?
>
> Use an RDBMS.
You don't understand that it can have nothing to do with a RDBMS. I'm
not talking about transaction control within the context of a database
within a RDBMS. As I wrote to another user on this list, say you have
two database servers and you need to implement a process which operates
on each database in order. Maybe you move an item from on to the other.
What if the second operation fails? Natually you want to roll-back to
before the operation on the first. That's what J2EE transactions are
about. See how RDMBS transactions are a different deal in this
situation?
===
Subject: Re: mod_perl advocacy project resurrection
From: brian moseley <bcm@maz.org>
Date: Tue, 5 Dec 2000 15:16:43 -0800 (PST)
On Tue, 5 Dec 2000, Matt Sergeant wrote:
> But I'd really love to hear some rational discussion on
> transaction object support. There are open source J2EE
> implementations - would it be possible to look a porting
> the transaction management components of that to Perl?
> Would this be desirable? Personally I put all
> transaction critical stuff in the database, and rely on
> RDBMS transaction support, but I've never done J2EE, so
> I'm curious as to the advantages.
transaction management, message queuing, container managed
persistence, a naming/directory interface, a monitoring
(snmp) framework, enterprise application integration...
these are all things in j2ee and associated products that we
don't have.
===
Subject: RE: mod_perl advocacy project resurrection
From: Perrin Harkins <perrin@primenet.com>
Date: Tue, 5 Dec 2000 16:00:32 -0800 (PST)
Brian, you've been taking a beating on this thread. I don't want to add
to it, but you did raise a couple of interesting questions in this post.
> the availability of application server products in the java world is
> another example. go look at enhydra enterprise
> (http://www.enhydra.org/software/enhydraEnterprise/) and tell me that
> something like that exists in the perl world.
Personally, I'm kind of pleased that nothing like that exists in the perl
world. It looks like a recipe for a slow site to me - complexity for the
sake of complexity. But I've been burned by Java "application servers"
before so I may be a bit prejudiced against Enhydra. I think the part of
server-side Java that has the most value is the basic servlet API.
Personally, I find it pretty easy to replicate those services in mod_perl
without doing any additional coding, but I know you believe it's still too
difficult for newbies, and you may be right.
Part of the problem then is that perl is all things to all people. This
thread has already covered both the "it's harder than PHP", which is true,
and the "it's not as polished as Java", wich is also true. Some projects,
like Embperl and Apache::ASP, have gone a long way to make the barriers to
entry lower for the PHP types. There has also been a lot of effort to
make more polished web pages and documentation for some mod_perl projects
lately, Mason and AxKit being cases in point. I doubt it will ever
compete with Java in this regard though, since no single mod_perl project
is likely to get the same level of promotion that a WebLogic can muster.
The mod_perl message will probably always be about choice, flexibility,
and source code.
> you don't have to spend time re-integrating Apache::Session and
> Apache::DBI and Apache::WipeMyAss with each new project.
I think Apache::WipeMyAss auto-configures as of 0.3. But seriously, do
people have that much trouble using these defacto standard modules?
Maybe they need some more work in certain areas if they don't function
correctly "out of the box" for most people.
===
Subject: Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
From: Dave Rolsky <autarch@urth.org>
Date: Tue, 5 Dec 2000 17:51:04 -0600 (CST)
On Tue, 5 Dec 2000, kyle dawkins wrote:
> * We need to drop-kick DBI out of the park... it's not that it's bad (it's
> actually great... kudos to the DBI crew) but kind of the opposite; it's so
> easy to use that most people don't think beyond it. How many of you have
> ever thought about implementing an Object-Relational middleware layer using
> mod_perl? We could create a set of generic OR classes as part of our
> foundation framework.
Please take a look at:
Alzabo (alzabo.sourceforge.net) - my own project
Tangram (www.tangram-persistence.org)
Those two are both very ambitious in terms of multiple DB support and
complete abstraction.
There are a number others that in a similar vein that are less ambitious
(IMO):
Class::DBI
DBIx::DBSchema
BingoX::Carbon
DbFramework
Those are all on CPAN. Of all of them, Tangram is by far the most mature.
It is also actively maintained. I know that the first three on the bottom
list, as well as Alzabo, are also being maintained.
===
Date: Tue, 5 Dec 2000 15:51:24 -0800 (PST)
From: Paul <ydbxmhc@yahoo.com>
Subject: RE: mod_perl advocacy project resurrection
To: modperl <modperl@apache.org>
--- brian moseley <bcm@maz.org> wrote:
[...]
> if we'd have been operating in a java environment, we'd have
> been able to take advantage of the "insanely great"
> JavaMail, which comes out of the box with an IMAP backend. a
> prototype IMAP re-implementation of our mail client took
> about 3 days, as opposed to the month or more it will take
> us to do the perl implementation.
[...]
Isn't that the point?
Java already has the tools, because there are more people writing for
it, because it's had more hype, because "it already has the tools...."
I love Java, but good luck if you've inherited a legacy machine for
which there is no convenient port of the Java version in which the
desired code is written. I'm stuck on an old HP T500 running HPUX
10.20, and the Java version on it is early 1.0. Java's great if you're
looking for something out-of-the-box like JavaMail, but if the advocacy
project succeeds there will *be* boxed Perl IMAP solutions, and all the
other stuff you already get with Java.
For me, I'd go Perl every time. I like PHP and Python and Expect, too,
but though I want to keep my hand in them all, but much like there's a
best language for most problems, there's also a best language for most
personalities. Java works great for the straight-laced type who wants
all the garbage collection and strict OO features and such; C is still
great for systems folk who *like* playing fast and loose with pointers
(and I'm guilty...); but Perl lets you write quick-and-dirties in
seconds, *as well* as giving you "use strict;" and object modules and a
pretty good GC system, even if it isn't as elaborate as Java's.
Call me an advocate!
===========================
From: Michael Nachbaur <MNachba@rei.com>
To: "'Perrin Harkins'" <perrin@primenet.com>,
Cc: "Thomas J. Mather" <tjmather@anidea.com>, modperl@apache.org
Subject: RE: mod_perl advocacy project resurrection
Date: Tue, 5 Dec 2000 15:50:16 -0800
> > Transaction support for your business logic is easy in
> J2EE. It's not > clear how you do this in Perl? Use an
> RDBMS.
This is exactly what people mean on this list about people
not understanding the principles of enterprise programming.
Its like trying to scape paint off of a glass window with a
sledge hammer. THere is absolutely no way to scale a system
which uses an RDBMS as a state / transaction support system
beyond 1 web server and 1 database server. How are you
going to scale to 10,000 simultaneous users? I've *seen*
systems with my own eyes that can do that, and I'm telling
you they do not use an RDBMS.
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org For
additional commands, e-mail: modperl-help@apache.org
From modperl-return-11668-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 17:10:04 2000
Return-Path: <modperl-return-11668-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id RAA38900
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 17:10:04 -0800 (PST)
(envelope-from modperl-return-11668-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 13232 invoked by uid 500); 5 Dec 2000 23:59:02 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 13190 invoked from network); 5 Dec 2000 23:59:00 -0000
Message-Id: <5.0.0.25.2.20001206074540.00a07960@mail.clark.net>
X-Sender: gunther@mail.clark.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 06 Dec 2000 07:50:21 +0800
To: "Thomas J. Mather" <tjmather@anidea.com>, modperl@apache.org
From: Gunther Birznieks <gunther@extropia.com>
Subject: Re: mod_perl advocacy project resurrection
In-Reply-To: <Pine.LNX.4.21.0012051306430.20811-100000@knut.anidea.com>
References: <14893.9576.32197.523801@kulon.arrakisplanet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
At 01:25 PM 12/5/00 -0500, Thomas J. Mather wrote:
>On Tue, 5 Dec 2000, Michael Nachbaur wrote:
>
>
>I guess what I'm getting at is that I hear a lot of marketing hype about
>Java being a better "enterprise solution", but I'm curious as to what are
>the purely technical reasons for using Java over Perl. What exactly can
>you do in Java that you can't do as easily in Perl?
1. Trivial to do multithreading and shared memory (in a
single server). Really nice for pools of cached
information. Single process model sucks for this.
2. Multithreading also allows tricks for doing server-side
callbacks more easily like making a servlet become a server
by listening on another port for callback information from
other servers.
3. The syntax is very strict and enforces cleaner
programming.
4. Cleaner RPC mechanisms. Most socket RPC mechanisms in
Perl are fairly hand-rolled. Java has RMI and even stuff
like SOAP and CORBA is way easier in Java than in Perl
because Java objects can be introspected and have their API
auto exported into the namespace.
5. True garbage collection instead of having to worry about
loops and unexpected memory leaks that result from those
loops. (Although to be fair the java binary itself can
leak).
I am not saying these are good things. But these are some
advantages for Java as an "Enterprise" language that can
make Perl a really annoying language to code for.
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11671-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 17:24:32 2000
Return-Path: <modperl-return-11671-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id RAA39017
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 17:24:32 -0800 (PST)
(envelope-from modperl-return-11671-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 22592 invoked by uid 500); 6 Dec 2000 00:08:10 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 22580 invoked from network); 6 Dec 2000 00:08:09 -0000
Date: Tue, 5 Dec 2000 16:09:33 -0800 (PST)
From: brian moseley <bcm@maz.org>
To: Perrin Harkins <perrin@primenet.com>
cc: Matthew Kennedy <mkennedy@hssinc.com>,
"Thomas J. Mather" <tjmather@anidea.com>, modperl@apache.org
Subject: Re: mod_perl advocacy project resurrection
In-Reply-To: <Pine.LNX.4.21.0012051438060.12595-100000@pharkins.office.etoys.com>
Message-ID: <Pine.LNX.4.21.0012051609071.14310-100000@rubel.maz.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Tue, 5 Dec 2000, Perrin Harkins wrote:
> > Transaction support for your business logic is easy in J2EE. It's not
> > clear how you do this in Perl?
>
> Use an RDBMS.
what about transactions that span data sources? yes, this
does happen.
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11673-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 17:28:02 2000
Return-Path: <modperl-return-11673-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id RAA39039
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 17:28:02 -0800 (PST)
(envelope-from modperl-return-11673-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 27706 invoked by uid 500); 6 Dec 2000 00:13:12 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 27692 invoked from network); 6 Dec 2000 00:13:11 -0000
X-Authentication-Warning: pharkins.office.etoys.com: pharkins owned process doing -bs
Date: Tue, 5 Dec 2000 16:29:14 -0800 (PST)
From: Perrin Harkins <perrin@primenet.com>
X-Sender: pharkins@pharkins.office.etoys.com
Reply-To: Perrin Harkins <perrin@primenet.com>
To: Michael Nachbaur <MNachba@rei.com>
cc: modperl@apache.org
Subject: RE: mod_perl advocacy project resurrection
In-Reply-To: <204640794C39D211A21700805FA735211026A262@ahqex1.rei.com>
Message-ID: <Pine.LNX.4.21.0012051617301.12595-100000@pharkins.office.etoys.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Tue, 5 Dec 2000, Michael Nachbaur wrote:
> This is exactly what people mean on this list about people not
> understanding the principles of enterprise programming.
Easy there. You don't know anything about me or how much traffic my site
handles.
> THere is absolutely no way to scale a system which uses an RDBMS as a
> state / transaction support system beyond 1 web server and 1 database
> server.
What do you mean? Most systems use a cluster of web servers and one
database server.
> How are you going to scale to 10,000 simultaneous users? I've *seen*
> systems with my own eyes that can do that, and I'm telling you they do
> not use an RDBMS.
Well, what do they use then? I'd be very interested to hear about a
better solution. I know that Yahoo uses custom file-based servers instead
of an RDBMS, but I doubt they have transaction support in it. It's easy
to build a storage system that's faster than Oracle (e.g. MySQL), but it's
hard to build one that does ACID transactions and still has better
performance and scalability. What have you seen that works?
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11674-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 17:35:03 2000
Return-Path: <modperl-return-11674-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id RAA39062
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 17:35:02 -0800 (PST)
(envelope-from modperl-return-11674-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 36369 invoked by uid 500); 6 Dec 2000 00:21:28 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 36345 invoked from network); 6 Dec 2000 00:21:27 -0000
Date: Tue, 5 Dec 2000 16:22:45 -0800 (PST)
From: brian moseley <bcm@maz.org>
To: Perrin Harkins <perrin@primenet.com>
cc: mod_perl list <modperl@apache.org>
Subject: RE: mod_perl advocacy project resurrection
In-Reply-To: <Pine.LNX.4.21.0012051457260.12595-100000@pharkins.office.etoys.com>
Message-ID: <Pine.LNX.4.21.0012051610150.14310-100000@rubel.maz.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Tue, 5 Dec 2000, Perrin Harkins wrote:
> Brian, you've been taking a beating on this thread. I
> don't want to add to it, but you did raise a couple of
> interesting questions in this post.
a beating? i don't think so at all, it's been one of the
most restrained threads on this range of topics in a long
while. and judging from the amount of personal mail i've
gotten, a lot of people seem to agree with me! :)
> Personally, I'm kind of pleased that nothing like that
> exists in the perl world. It looks like a recipe for a
> slow site to me - complexity for the sake of complexity.
> But I've been burned by Java "application servers"
> before so I may be a bit prejudiced against Enhydra. I
> think the part of server-side Java that has the most
> value is the basic servlet API. Personally, I find it
> pretty easy to replicate those services in mod_perl
> without doing any additional coding, but I know you
> believe it's still too difficult for newbies, and you
> may be right.
cool, you should get a lot of use out of AO then :) i
definitely understand your viewpoint, and i realize that
there will be a lot of people who don't need the kinds of
things i'm proposing. but there are also a lot who do want
these types of components, and they really don't have any
options.
> Part of the problem then is that perl is all things to
> all people. This thread has already covered both the
> "it's harder than PHP", which is true, and the "it's not
> as polished as Java", wich is also true. Some projects,
> like Embperl and Apache::ASP, have gone a long way to
> make the barriers to entry lower for the PHP types.
> There has also been a lot of effort to make more
> polished web pages and documentation for some mod_perl
> projects lately, Mason and AxKit being cases in point.
> I doubt it will ever compete with Java in this regard
> though, since no single mod_perl project is likely to
> get the same level of promotion that a WebLogic can
> muster. The mod_perl message will probably always be
> about choice, flexibility, and source code.
eh, there's a perl infrastructure support/services company
waiting to happen. i just personally don't have the
motivation to do something on the scale that i think is
necessary. maybe this discussion is giving others ideas,
tho...
> I think Apache::WipeMyAss auto-configures as of 0.3.
> But seriously, do people have that much trouble using
> these defacto standard modules? Maybe they need some
> more work in certain areas if they don't function
> correctly "out of the box" for most people.
i think a lot of it is that they are all configured in
different ways, and you have to write glue code to tie them
all together. a good example is the stuff you have to do to
configure mason. dave's implementing apache config
directives for some of that, which i think is a good step,
but i personally don't like having the configuration of my
application mixed up with the configuration of my web
server. so one of the things that AO has is a nice flexible
configuration system which allows all these various knobs to
be tweaked in one place, with no code writing. the net
effect is that it's extremely simple to clone a template
servlet app, spend 30 seconds tweaking, and have a running
app with authen and authz, session persistence, logging,
etc. it's all the same glue code shit i used to write for
each of my projects, now it's reusable and packaged up
neatly with a bow tie. rad.
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11675-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 17:40:55 2000
Return-Path: <modperl-return-11675-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id RAA39150
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 17:40:55 -0800 (PST)
(envelope-from modperl-return-11675-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 38912 invoked by uid 500); 6 Dec 2000 00:23:53 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 38864 invoked from network); 6 Dec 2000 00:23:51 -0000
X-Authentication-Warning: pharkins.office.etoys.com: pharkins owned process doing -bs
Date: Tue, 5 Dec 2000 16:39:13 -0800 (PST)
From: Perrin Harkins <perrin@primenet.com>
X-Sender: pharkins@pharkins.office.etoys.com
Reply-To: Perrin Harkins <perrin@primenet.com>
To: brian moseley <bcm@maz.org>
cc: modperl@apache.org
Subject: Re: mod_perl advocacy project resurrection
In-Reply-To: <Pine.LNX.4.21.0012051609071.14310-100000@rubel.maz.org>
Message-ID: <Pine.LNX.4.21.0012051629520.12595-100000@pharkins.office.etoys.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Tue, 5 Dec 2000, brian moseley wrote:
> On Tue, 5 Dec 2000, Perrin Harkins wrote:
>
> > > Transaction support for your business logic is easy in J2EE. It's not
> > > clear how you do this in Perl?
> >
> > Use an RDBMS.
>
> what about transactions that span data sources? yes, this
> does happen.
Someone else brought this up with me off the list. Briefly, I said that
this doesn't usually happen with web sites for performance reasons and
that major RDBMS vendors offer things like two-phase commit. But no,
there is no perl transaction service that I know of. You'd have to look
at interfacing with a commercial TP monitor for that, and those are
more likely to have hooks already written for Java.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11676-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 17:47:56 2000
Return-Path: <modperl-return-11676-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id RAA39209
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 17:47:55 -0800 (PST)
(envelope-from modperl-return-11676-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 42271 invoked by uid 500); 6 Dec 2000 00:27:42 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 42259 invoked from network); 6 Dec 2000 00:27:41 -0000
Date: Tue, 5 Dec 2000 16:29:06 -0800 (PST)
From: brian moseley <bcm@maz.org>
To: Perrin Harkins <perrin@primenet.com>
cc: modperl@apache.org
Subject: Re: mod_perl advocacy project resurrection
In-Reply-To: <Pine.LNX.4.21.0012051629520.12595-100000@pharkins.office.etoys.com>
Message-ID: <Pine.LNX.4.21.0012051625300.14310-100000@rubel.maz.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Tue, 5 Dec 2000, Perrin Harkins wrote:
> Someone else brought this up with me off the list.
> Briefly, I said that this doesn't usually happen with
> web sites for performance reasons and that major RDBMS
the world doesn't revolve around two tier web sites.
consider a scenario in which somebody uses a web interface
to signal an action, which is placed into a message queue.
on the other end of that queue, a service handles the event
with a transaction that spans multiple third tier systems.
this is the kind of architecture that is begging to be
embraced by perl.
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11679-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 18:04:20 2000
Return-Path: <modperl-return-11679-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id SAA39272
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 18:04:19 -0800 (PST)
(envelope-from modperl-return-11679-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 65155 invoked by uid 500); 6 Dec 2000 00:47:13 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 65137 invoked from network); 6 Dec 2000 00:47:12 -0000
Date: Tue, 5 Dec 2000 16:48:32 -0800 (PST)
From: brian moseley <bcm@maz.org>
To: Gunther Birznieks <gunther@extropia.com>
cc: mod_perl list <modperl@apache.org>
Subject: Re: RFC: mod_perl advocacy project resurrection
In-Reply-To: <5.0.0.25.2.20001206072359.00a007f0@mail.clark.net>
Message-ID: <Pine.LNX.4.21.0012051645150.14310-100000@rubel.maz.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Wed, 6 Dec 2000, Gunther Birznieks wrote:
> I think the issue is Perl for web applications advocacy
> rather than mod_perl advocacy. If more people thought
> using Perl for web apps was cooler and easier than using
> PHP, then they would use Perl and then graduate to
> mod_perl when they were ready.
well said.
> As it is, PHP has 1-up on CGI/Perl. PHP is FAST while
> still having an easy programming model. Having an easy
> programming model was Perl's claim to fame and why web
> apps fluorished in CGI/Perl. But PHP added one thing --
> speed -- and they are taking it all away from Perl.
well there's also the in-core support for things like
database access, imap, etc etc. it's very easy to go to the
php manual and look up the api for interacting with these
services. you don't have to go to some component archive,
look for something that suits, choose between 3 or 4
components that all do the same thing but in different ways,
figure out how to configure the thing and work it into your
build, etc.
> The model is similar to FastCGI, but SpeedyCGI is
> trivial to setup unlike FastCGI which requires
> modification to the app.
yeah, one of the main goals of AO is to be portable between
mod_perl, FastCGI, SpeedyCGI and other process models. app
writers should be able to assume that the servlet
environment provides a standard set of services without
having to understand HOW, if that's their choice.
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11680-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 18:44:41 2000
Return-Path: <modperl-return-11680-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id SAA39575
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 18:44:41 -0800 (PST)
(envelope-from modperl-return-11680-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 67524 invoked by uid 500); 6 Dec 2000 02:06:22 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 67512 invoked from network); 6 Dec 2000 02:06:22 -0000
Date: Tue, 5 Dec 2000 18:05:54 -0800 (PST)
From: "Jeffrey W. Baker" <jwbaker@acm.org>
X-Sender: jwb@heat.dci
To: Perrin Harkins <perrin@primenet.com>
cc: brian moseley <bcm@maz.org>, mod_perl list <modperl@apache.org>
Subject: RE: mod_perl advocacy project resurrection
In-Reply-To: <Pine.LNX.4.21.0012051457260.12595-100000@pharkins.office.etoys.com>
Message-ID: <Pine.LNX.4.21.0012051759020.12153-100000@heat.dci>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Tue, 5 Dec 2000, Perrin Harkins wrote:
> Brian, you've been taking a beating on this thread. I don't want to add
> to it, but you did raise a couple of interesting questions in this post.
>
> > the availability of application server products in the java world is
> > another example. go look at enhydra enterprise
> > (http://www.enhydra.org/software/enhydraEnterprise/) and tell me that
> > something like that exists in the perl world.
>
> Personally, I'm kind of pleased that nothing like that exists in the perl
> world. It looks like a recipe for a slow site to me - complexity for the
> sake of complexity. But I've been burned by Java "application servers"
> before so I may be a bit prejudiced against Enhydra. I think the part of
> server-side Java that has the most value is the basic servlet API.
> Personally, I find it pretty easy to replicate those services in mod_perl
> without doing any additional coding, but I know you believe it's still too
> difficult for newbies, and you may be right.
The Big Thing for a serious project is providing a lot of services. If
you look at Weblogic server, you get all database, sessions, message
queuing, directory access, blah blah blah for free. Basically, the
programmer lives in a little cocoon where a truckload of services are
available and he only has to worry about his code.
Contrast that with a mod_perl server. Out of the box, the only thing you
get is a request object. I love that, and that's why if I want to add a
little widget to my intranet, of course I do it in mod_perl and it takes
me 15 minutes. But growing is nearly impossible. Adding data access,
session management, and the like require work on the part of the
programmer, and I think this list can testify that a lot of people don't
do it properly.
I haven't looked at AO or AxKit, but if I can untar either one of them and
just get to work, that will rule. (An aside: you can literally just unzip
weblogic.zip and start it. It is extremely simple, and it hasn't been
"slow" in years.)
> Part of the problem then is that perl is all things to all people. This
> thread has already covered both the "it's harder than PHP", which is true,
> and the "it's not as polished as Java", wich is also true. Some projects,
> like Embperl and Apache::ASP, have gone a long way to make the barriers to
> entry lower for the PHP types. There has also been a lot of effort to
> make more polished web pages and documentation for some mod_perl projects
> lately, Mason and AxKit being cases in point. I doubt it will ever
> compete with Java in this regard though, since no single mod_perl project
> is likely to get the same level of promotion that a WebLogic can muster.
> The mod_perl message will probably always be about choice, flexibility,
> and source code.
>
> > you don't have to spend time re-integrating Apache::Session and
> > Apache::DBI and Apache::WipeMyAss with each new project.
>
> I think Apache::WipeMyAss auto-configures as of 0.3. But seriously, do
> people have that much trouble using these defacto standard modules?
> Maybe they need some more work in certain areas if they don't function
> correctly "out of the box" for most people.
There are a whole lot of people who just can't understand how to install
Apache::Session. They shouldn't need to.
-jwb
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11683-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 18:49:57 2000
Return-Path: <modperl-return-11683-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id SAA39629
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 18:49:57 -0800 (PST)
(envelope-from modperl-return-11683-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 73455 invoked by uid 500); 6 Dec 2000 02:13:25 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 73438 invoked from network); 6 Dec 2000 02:13:25 -0000
Date: Tue, 5 Dec 2000 20:50:55 -0500
From: Ajit Deshpande <ajit@skycorp.net>
To: brian moseley <bcm@maz.org>
Cc: Perrin Harkins <perrin@primenet.com>, modperl@apache.org
Subject: Re: mod_perl advocacy project resurrection
Message-ID: <20001205205055.A18235@sky.skycorp.net>
References: <Pine.LNX.4.21.0012051629520.12595-100000@pharkins.office.etoys.com> <Pine.LNX.4.21.0012051625300.14310-100000@rubel.maz.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <Pine.LNX.4.21.0012051625300.14310-100000@rubel.maz.org>; from brian moseley on Tue, Dec 05, 2000 at 04:29:06PM -0800
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Tue, Dec 05, 2000 at 04:29:06PM -0800, brian moseley wrote:
> consider a scenario in which somebody uses a web interface
> to signal an action, which is placed into a message queue.
> on the other end of that queue, a service handles the event
> with a transaction that spans multiple third tier systems.
wouldnt such a system be better off hand-crafted with an RDBMS and nicely
laid out perl modules? why would you want to get stuck with a proprietary
application framework for such a case? technically/programmatically there
is not much invloved in doing something like this. its more of a design
issue than a programming issue. the Java based transaction
servers may have been designed and architected with good extensibility,
but i tend to feel that a hand-crafted system is going to be more robust
and extensible. i have had first-hand experience with so-called
enterprise tools from HP OpenView and they have miserably failed to meet
our requirements time and again. the Java based transaction monitors may
be better, but i remain skeptical..
> this is the kind of architecture that is begging to be
> embraced by perl.
absolutely. but that would be similar to making the same mistake that
companies like CommerceOne and Ariba are making: namely, portending to
build a piece of software that will satisfy the business needs from
companies in different business-verticals.
the gist of my argument is that systems like these just do not lend
themselves very easily to the diverse web-app-infrastructure that
enterprises will want to deploy.
ajit
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11684-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 18:55:37 2000
Return-Path: <modperl-return-11684-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id SAA39707
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 18:55:36 -0800 (PST)
(envelope-from modperl-return-11684-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 80491 invoked by uid 500); 6 Dec 2000 02:18:57 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 80469 invoked from network); 6 Dec 2000 02:18:57 -0000
Date: Tue, 5 Dec 2000 18:18:30 -0800 (PST)
From: "Jeffrey W. Baker" <jwbaker@acm.org>
X-Sender: jwb@heat.dci
To: brian moseley <bcm@maz.org>
cc: Perrin Harkins <perrin@primenet.com>,
Matthew Kennedy <mkennedy@hssinc.com>,
"Thomas J. Mather" <tjmather@anidea.com>, modperl@apache.org
Subject: Re: mod_perl advocacy project resurrection
In-Reply-To: <Pine.LNX.4.21.0012051609071.14310-100000@rubel.maz.org>
Message-ID: <Pine.LNX.4.21.0012051814090.12153-100000@heat.dci>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Tue, 5 Dec 2000, brian moseley wrote:
> On Tue, 5 Dec 2000, Perrin Harkins wrote:
>
> > > Transaction support for your business logic is easy in J2EE. It's not
> > > clear how you do this in Perl?
> >
> > Use an RDBMS.
>
> what about transactions that span data sources? yes, this
> does happen.
Yeah, it *seems* to happen, but it doesn't actually. Any vendor who tells
you he can do real transactions across data sources is a liar, or using a
new and improved definition of transaction. You can do it %99.99 of the
time but that last %.01 is the bitch.
With J2EE you get the complete illusion that you are doing txns across as
many data sources on as many systems and vendors as you want, but behind
the illusion there is the nonzero risk that the data is inconsistent. In
a real transactional system, you can never have inconsistent data.
Lesson: you can sell most people an illusion :)
-jwb
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11685-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 19:11:30 2000
Return-Path: <modperl-return-11685-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id TAA39767
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 19:11:30 -0800 (PST)
(envelope-from modperl-return-11685-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 5572 invoked by uid 500); 6 Dec 2000 02:45:25 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 5539 invoked from network); 6 Dec 2000 02:45:23 -0000
Date: Tue, 5 Dec 2000 18:46:49 -0800 (PST)
From: brian moseley <bcm@maz.org>
To: Ajit Deshpande <ajit@skycorp.net>
cc: modperl@apache.org
Subject: Re: mod_perl advocacy project resurrection
In-Reply-To: <20001205205055.A18235@sky.skycorp.net>
Message-ID: <Pine.LNX.4.21.0012051843310.14310-100000@rubel.maz.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Tue, 5 Dec 2000, Ajit Deshpande wrote:
> wouldnt such a system be better off hand-crafted with an
> RDBMS and nicely laid out perl modules? why would you
> want to get stuck with a proprietary application
> framework for such a case? technically/programmatically
maybe /you/ would. the real argument i'm making is that
there are tools to address the 80% case that do not exist.
so /everybody/ is hand crafting. that's just obviously
inefficient. in almost ever scenario i've been exposed to,
the 80% case doesn't justify a cottage industry.
oh - where did you get proprietary from? who suggested that?
not me.
> the gist of my argument is that systems like these just
> do not lend themselves very easily to the diverse
> web-app-infrastructure that enterprises will want to
> deploy.
you might be right, but i don't believe you :)
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11686-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 19:22:25 2000
Return-Path: <modperl-return-11686-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id TAA39822
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 19:22:24 -0800 (PST)
(envelope-from modperl-return-11686-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 36431 invoked by uid 500); 6 Dec 2000 03:17:30 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 36420 invoked from network); 6 Dec 2000 03:17:27 -0000
Date: Tue, 5 Dec 2000 21:17:51 -0600 (CST)
From: Dave Rolsky <autarch@urth.org>
To: brian moseley <bcm@maz.org>
cc: mod_perl list <modperl@apache.org>
Subject: Re: mod_perl advocacy project resurrection (messaging system)
In-Reply-To: <Pine.LNX.4.21.0012051625300.14310-100000@rubel.maz.org>
Message-ID: <Pine.LNX.4.30.0012052117070.5398-100000@urth.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Tue, 5 Dec 2000, brian moseley wrote:
> consider a scenario in which somebody uses a web interface
> to signal an action, which is placed into a message queue.
> on the other end of that queue, a service handles the event
> with a transaction that spans multiple third tier systems.
>
> this is the kind of architecture that is begging to be
> embraced by perl.
Re: a messaging system
Check out Uri Guttmans Stem code (email him about it) at
www.stemsystems.com
-dave
/*==================
www.urth.org
We await the New Sun
==================*/
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11687-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 19:35:17 2000
Return-Path: <modperl-return-11687-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id TAA39870
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 19:35:16 -0800 (PST)
(envelope-from modperl-return-11687-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 42596 invoked by uid 500); 6 Dec 2000 03:34:34 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Delivered-To: moderator for modperl@apache.org
Received: (qmail 75420 invoked from network); 5 Dec 2000 23:27:33 -0000
Date: Wed, 6 Dec 2000 12:28:04 +1300
From: Stuart Frew <stuart@nzr.co.nz>
To: modperl@apache.org
Subject: RE: mod_perl advocacy project resurrection
Message-ID: <20001206122804.W858@grinch>
References: <204640794C39D211A21700805FA735211026A261@ahqex1.rei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
In-Reply-To: <204640794C39D211A21700805FA735211026A261@ahqex1.rei.com>; from MNachba@rei.com on Wed, Dec 06, 2000 at 11:01:16 +1300
X-Mailer: Balsa 1.0.0
Lines: 105
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
>From my experiance with using the Enterprise solutions is that you pay a
yearly maintenace to be told to upgrade to a the next version.
Also you can create unmaintainable spagettie not matter the tool.
As to intergration support, I have found that when you really need that
intergration feature it is vapourware.
Of course I may just have the unfortunate luck to have dealt with
disreputable vendors.
However this is beside the point. You should use the right tool for the job
at hand.
I am sure there are somethings where mod-perl is not the correct tool, some
where it does not matter, and others where it is the best.
We can not be all things to all people, which I find is where most
enterprise solutions fall down.
Cheers Stuart
On 2000.12.06 11:01:16 +1300 Michael Nachbaur wrote:
> The issue here is not the underlying architecture. I have seen so-called
> "Enterprise" solutions which are based on the most flakey of ideas, but
> are sold with a $150k+ pricetag. Why? Because of the integraiton.
> Because of the support.
>
> I a large company, you cannot *afford* to have the ubergeek cureall
> solution. What if the guy gets hit by a bus? What if he goes to another
> company? You can't afford that kind of situation. What do you do in
> that case? Make the system easy enough to use and understand, that you
> can have 5-ubergeek types at the company. Sure the system isn't a
> screamer, but atleast it doesn't take a genious to understand.
>
> Also, systems like EmbPerl, HTML::Mason and Axkit/Cocoon work wonders for
> shops with under 10 developers. What happens when you have 20
> programmers, 15 workflow people, 45 content creators, 10 photographers,
> 20 HTML designers / producers, 30 merchandisers, 30 marketers and a host
> of misc. consultant copywriters? How do you coordinate everything? A
> large online retailer, news site, portal, you name it...has a *lot* of
> employees. *That* is what an Enterprise is...and anyone who says you can
> "get by" with an HTML::Mason is diluted.
>
> Now, I use HTML::Mason, and I love it...for my personal website. I'm
> sure many organizations can get by with it. But, thats not what I'm
> talking about, and thats where Java is winning. What happens when all
> those programmers working on Java solutions decide to build something at
> home? They'll use Java.
>
> If you remember, Apple tried to appeal to schools and home users, and M$
> focused on business. Who has all the marketshare now?
>
> The answer isn't in the hobbiest or in the small sites. For longevity
> and mindshare, you must go into the big businesses.
>
> My company is a Perl shop, through and through. We would rather go to
> Perl, but the problem is that theres *nothing* out there. Please prove
> me wrong.
>
> --man
> Michael A. Nachbaur
>
> -----Original Message-----
> From: Thomas J. Mather [mailto:tjmather@anidea.com]
> Sent: Tuesday, December 05, 2000 10:25 AM
> To: modperl@apache.org
> Subject: Re: mod_perl advocacy project resurrection
>
>
> On Tue, 5 Dec 2000, Michael Nachbaur wrote:
>
> > I don't know what I'm getting at here, but I see that Perl is half a
> > step behind Java in many ways, except for the performance issues
> > (which perl is leagues ahead). For my company, we're probably going
> > Java, but it sorta makes sense for us (we need an enterprise solution
> > now...not when the Perl community gets around to it).
>
> How exactly does Java provide a better "enterprise solution" than
> Perl? And how can the Perl community better provide an "enterprise
> solution"?
>
> It is true that Java code is generally more cleaner and easier to
> maintain
> than Perl code, but this is because Perl allows you to write bad code,
> while Java enforces typing and OO design. A good Perl coder should
> be able to write code that is clean and easy to maintain by following
> coding guidelines, and by using OO modules and 'use strict'.
>
> I guess what I'm getting at is that I hear a lot of marketing hype about
> Java being a better "enterprise solution", but I'm curious as to what are
> the purely technical reasons for using Java over Perl. What exactly can
> you do in Java that you can't do as easily in Perl?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: modperl-unsubscribe@apache.org
> For additional commands, e-mail: modperl-help@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: modperl-unsubscribe@apache.org
> For additional commands, e-mail: modperl-help@apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11689-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 20:38:51 2000
Return-Path: <modperl-return-11689-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id UAA40174
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 20:38:51 -0800 (PST)
(envelope-from modperl-return-11689-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 67015 invoked by uid 500); 6 Dec 2000 04:37:14 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 66929 invoked from network); 6 Dec 2000 04:37:12 -0000
Date: Tue, 5 Dec 2000 20:37:02 -0800 (PST)
From: Michael Robinton <michael@bizsystems.com>
X-Sender: michael@pandora.is.bizsystems.com
To: mod_perl list <modperl@apache.org>
Subject: RE: mod_perl advocacy project resurrection
In-Reply-To: <Pine.LNX.4.21.0012051759020.12153-100000@heat.dci>
Message-ID: <Pine.LNX.3.91.1001205203251.12574B-100000@pandora.is.bizsystems.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Tue, 5 Dec 2000, Jeffrey W. Baker wrote:
> On Tue, 5 Dec 2000, Perrin Harkins wrote:
>
> > Brian, you've been taking a beating on this thread. I don't want to add
> > to it, but you did raise a couple of interesting questions in this post.
> >
<snip>
> The Big Thing for a serious project is providing a lot of services. If
> you look at Weblogic server, you get all database, sessions, message
> queuing, directory access, blah blah blah for free. Basically, the
> programmer lives in a little cocoon where a truckload of services are
> available and he only has to worry about his code.
>
<snip>
> > Maybe they need some more work in certain areas if they don't function
> > correctly "out of the box" for most people.
>
> There are a whole lot of people who just can't understand how to install
> Apache::Session. They shouldn't need to.
>
Give a man a dump truck full of leggos, motors and gears and you can build
some really interesting stuff, give man an end mill or a lathe and he can
build a rocket ship to the moon. You figure out which one is Weblogic and
which one is Apache-modperl :-)
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11690-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Tue Dec 5 21:14:07 2000
Return-Path: <modperl-return-11690-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id VAA40389
for <doom@kzsu.stanford.edu>; Tue, 5 Dec 2000 21:14:06 -0800 (PST)
(envelope-from modperl-return-11690-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 89380 invoked by uid 500); 6 Dec 2000 05:13:28 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 89369 invoked from network); 6 Dec 2000 05:13:27 -0000
Date: Wed, 6 Dec 2000 00:26:49 -0500
From: Chris Winters <chris@cwinters.com>
To: Ben Cottrell <benco@stockmaster.com>
Cc: mod_perl list <modperl@apache.org>
Subject: Re: mod_perl advocacy project resurrection
Message-ID: <20001206002649.C31759@genesee.intes.net>
References: <Pine.LNX.4.21.0012051240220.14310-100000@rubel.maz.org> <200012052158.QAA05788@west2.stockmaster.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200012052158.QAA05788@west2.stockmaster.com>; from benco@stockmaster.com on Tue, Dec 05, 2000 at 04:58:56PM -0500
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
* Ben Cottrell (benco@stockmaster.com) [001205 18:15]:
> ...
>
> Just one example... my company ran into a bug in mod_perl a while ago...
> so what did we do? we fixed it, and submitted a patch. If we'd been
> using the J-word, we'd have been stuck. Tell me one big-name app server
> that's written in C and that'll let you download the source and fix
> bugs.
Hi Ben,
Well, you could always use one of the open-source Java application
servers (among others):
JBoss: http://www.jboss.org/
JOnAS: http://www.evidian.com/jonas/
(Future) OpenEJB: http://www.exolab.org/
Along with the open-source Servlet/JSP/Web Engine servers (among
others):
Apache Tomcat: http://jakarta.apache.org/
Jetty: http://jetty.mortbay.com/
'Java' and 'open-source' are not mutually exclusive :-)
This whole discussion has been extremely timely for me since I just
left a position doing 100% Perl -- mostly mod_perl, building a web
application environment at http://www.openinteract.org/ which won't be
formally announced until January -- for one doing mostly Java web
development.
I wasn't sure exactly what I'd find, but what I've come across matches
more with what Brian has been saying than what Dave said in his (IMO)
rude dismissal of Java programmers. Java has the advantage of a
well-funded company behind it to put out consistent and generally well
thought out APIs and products. The whole Enterprise Javabean and J2EE
environment is maturing rapidly and allows you to build complicated
applications very quickly.
And the perception out there, unlike with mod_perl, is that you don't
need to be a wizard to build such applications. Maybe that's because
there are more books, maybe that's because of the marketing machine,
maybe that's because IDEs will give you some hand-holding along the
way -- I dunno.
One of the things that's surprised me the most is the amount and
quality of open-source Java software available. I had the idea that
Java was more "corporate" and wouldn't attract OS people like Perl or
C (or Python or...). In fact, some software packages (like various
regex engines) are meant to fill gaps that people find when they use
Java from a background of using Perl.
Oh well. It's late and my brain is all mushy from learning this Java
stuff :-)
Chris
--
Chris Winters (chris@cwinters.com)
Building enterprise-capable snack solutions since 1988.
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11695-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Wed Dec 6 00:12:28 2000
Return-Path: <modperl-return-11695-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id AAA41191
for <doom@kzsu.stanford.edu>; Wed, 6 Dec 2000 00:12:27 -0800 (PST)
(envelope-from modperl-return-11695-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 2698 invoked by uid 500); 6 Dec 2000 08:10:41 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Delivered-To: moderator for modperl@apache.org
Received: (qmail 23058 invoked from network); 6 Dec 2000 06:06:48 -0000
From: Jim Woodgate <woody@realtime.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 6 Dec 2000 00:06:34 -0600 (CST)
To: Chris Winters <chris@cwinters.com>
Cc: Ben Cottrell <benco@stockmaster.com>, mod_perl list <modperl@apache.org>
Subject: Re: mod_perl advocacy project resurrection
In-Reply-To: <20001206002649.C31759@genesee.intes.net>
References: <Pine.LNX.4.21.0012051240220.14310-100000@rubel.maz.org>
<200012052158.QAA05788@west2.stockmaster.com>
<20001206002649.C31759@genesee.intes.net>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid
Message-ID: <14893.53574.96903.706454@cs167119-96.austin.rr.com>
Reply-To: woody@bga.com
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
Chris Winters writes:
> Along with the open-source Servlet/JSP/Web Engine servers (among
> others):
>
> Apache Tomcat: http://jakarta.apache.org/
> Jetty: http://jetty.mortbay.com/
>
I'm currently using the Tomcat at work, and I have to say that
although I really love perl and mod_perl, there are real advantages to
using java. Over the past couple of years that I've been mostly
lurking on this list there have been a couple common threads:
1) Memory Usage: embedding the perl interpreter on every process uses
lots of memory. This of course can be tweaked and isn't as bad on
good OS's, but it is a common thread.
2) Sharing information between the processes. There's lots of
different ways to do it, but none really jumps out as an end-all
solution.
With a system like Tomcat running in a jvm outside of apache, you only
have one jvm, and you get things like being able to share a cache
between all sessions alot easier.
I personally find the configuration of mod_perl to be more straight
forward than Tomcat, but I do see some advantages to that system (I'm
sure there are some speed disadvantages to the tomcat communcation,
but haven't done any benchmarks).
That being said, I wonder how difficult it would be pull the perl
intepreter out of mod_perl and run a perl stand-alone multi-threaded
daemon which listens for mod_perl api calls... :)
Things I would never even try with java:
1) Talking any client/server protocol other than URLs. The perl
mail/ftp modules are so easy to use and they work great. I don't even
want to think about writing to syslogd from inside java... :)
2) Spawning an external process. I try not do it in mod_perl, but I
have never been able to pull it off in java.
--
woody@bga.com
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11696-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Wed Dec 6 00:18:40 2000
Return-Path: <modperl-return-11696-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id AAA41205
for <doom@kzsu.stanford.edu>; Wed, 6 Dec 2000 00:18:39 -0800 (PST)
(envelope-from modperl-return-11696-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 7922 invoked by uid 500); 6 Dec 2000 08:17:58 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 7898 invoked from network); 6 Dec 2000 08:17:56 -0000
Date: Wed, 6 Dec 2000 02:18:19 -0600 (CST)
From: Dave Rolsky <autarch@urth.org>
To: <woody@bga.com>
cc: mod_perl list <modperl@apache.org>
Subject: Re: mod_perl advocacy project resurrection
In-Reply-To: <14893.53574.96903.706454@cs167119-96.austin.rr.com>
Message-ID: <Pine.LNX.4.30.0012060216320.6729-100000@urth.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Wed, 6 Dec 2000, Jim Woodgate wrote:
> With a system like Tomcat running in a jvm outside of apache, you only
> have one jvm, and you get things like being able to share a cache
> between all sessions alot easier.
>
[snip]
>
> That being said, I wonder how difficult it would be pull the perl
> intepreter out of mod_perl and run a perl stand-alone multi-threaded
> daemon which listens for mod_perl api calls... :)
There is Velocigen and SpeedyCGI (or is it FastCGI?). These basically
create a pool of perl interpreter daemons that respond to requests.
The problem with them compared to mod_perl is that you don't have access
to the server internals so you can really only affect the content handling
phase. Is this the case with Tomcat as well?
If so, I'd say its not really comparable to mod_perl.
-dave
/*==================
www.urth.org
We await the New Sun
==================*/
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11697-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Wed Dec 6 00:42:17 2000
Return-Path: <modperl-return-11697-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id AAA41281
for <doom@kzsu.stanford.edu>; Wed, 6 Dec 2000 00:42:17 -0800 (PST)
(envelope-from modperl-return-11697-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 19066 invoked by uid 500); 6 Dec 2000 08:41:30 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 19055 invoked from network); 6 Dec 2000 08:41:28 -0000
Message-Id: <5.0.0.25.2.20001206164103.02a46800@mail.clark.net>
X-Sender: gunther@mail.clark.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 06 Dec 2000 16:43:58 +0800
To: mod_perl list <modperl@apache.org>
From: Gunther Birznieks <gunther@extropia.com>
Subject: Re: mod_perl advocacy project resurrection
In-Reply-To: <Pine.LNX.4.30.0012060216320.6729-100000@urth.org>
References: <14893.53574.96903.706454@cs167119-96.austin.rr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
At 02:18 AM 12/6/2000 -0600, Dave Rolsky wrote:
>On Wed, 6 Dec 2000, Jim Woodgate wrote:
>
> > With a system like Tomcat running in a jvm outside of apache, you only
> > have one jvm, and you get things like being able to share a cache
> > between all sessions alot easier.
> >
>[snip]
> >
> > That being said, I wonder how difficult it would be pull the perl
> > intepreter out of mod_perl and run a perl stand-alone multi-threaded
> > daemon which listens for mod_perl api calls... :)
>
>There is Velocigen and SpeedyCGI (or is it FastCGI?). These basically
>create a pool of perl interpreter daemons that respond to requests.
>
>The problem with them compared to mod_perl is that you don't have access
>to the server internals so you can really only affect the content handling
>phase. Is this the case with Tomcat as well?
Yes this is the case with tomcat.
>If so, I'd say its not really comparable to mod_perl.
It is very comparable. In the advocacy of mod_perl we are talking about
losing MAJOR ground to PHP and Java from a web applications development
perspective. So I think it is comparable.
The fact that mod_perl can modify the internals of apache is an icing on
the cake to most real-world programmers and won't make them use mod_perl or
Perl at all until it becomes as easy as PHP.
SpeedyCGI and TomCat are really very easy to get up and running and coding
away compared to mod_perl.
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11698-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Wed Dec 6 00:54:12 2000
Return-Path: <modperl-return-11698-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id AAA41325
for <doom@kzsu.stanford.edu>; Wed, 6 Dec 2000 00:54:12 -0800 (PST)
(envelope-from modperl-return-11698-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 27031 invoked by uid 500); 6 Dec 2000 08:53:13 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 27019 invoked from network); 6 Dec 2000 08:53:12 -0000
Message-Id: <5.0.0.25.2.20001206165435.00a98788@mail.clark.net>
X-Sender: gunther@mail.clark.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 06 Dec 2000 16:55:37 +0800
To: mod_perl list <modperl@apache.org>
From: Gunther Birznieks <gunther@extropia.com>
Subject: Re: mod_perl advocacy project resurrection
In-Reply-To: <20001206002649.C31759@genesee.intes.net>
References: <200012052158.QAA05788@west2.stockmaster.com>
<Pine.LNX.4.21.0012051240220.14310-100000@rubel.maz.org>
<200012052158.QAA05788@west2.stockmaster.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
At 12:26 AM 12/6/2000 -0500, Chris Winters wrote:
>And the perception out there, unlike with mod_perl, is that you don't
>need to be a wizard to build such applications. Maybe that's because
>there are more books, maybe that's because of the marketing machine,
>maybe that's because IDEs will give you some hand-holding along the
>way -- I dunno.
And some of those are open source IDEs. I really love using Forte's
community edition. It's integration to CVS is really nice too.
Has anyone written a Perl IDE in Perl?
Later,
Gunther
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11699-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Wed Dec 6 01:06:53 2000
Return-Path: <modperl-return-11699-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id BAA41360
for <doom@kzsu.stanford.edu>; Wed, 6 Dec 2000 01:06:53 -0800 (PST)
(envelope-from modperl-return-11699-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 33872 invoked by uid 500); 6 Dec 2000 09:06:16 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 33861 invoked from network); 6 Dec 2000 09:06:15 -0000
Date: Wed, 6 Dec 2000 09:06:15 +0000 (GMT)
From: Matt Sergeant <matt@sergeant.org>
To: "(Matthew Kennedy)" <mkennedy@hssinc.com>
cc: <modperl@apache.org>
Subject: Re: mod_perl advocacy project resurrection
In-Reply-To: <3A2D7663.B3B37BEE@opushealthcare.com>
Message-ID: <Pine.LNX.4.30.0012060902060.22298-100000@ted.sergeant.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Tue, 5 Dec 2000, (Matthew Kennedy) wrote:
> > > Transaction support for your business logic is easy in J2EE. It's not
> > > clear how you do this in Perl?
> >
> > Use an RDBMS.
>
> You don't understand that it can have nothing to do with a RDBMS. I'm
> not talking about transaction control within the context of a database
> within a RDBMS. As I wrote to another user on this list, say you have
> two database servers and you need to implement a process which operates
> on each database in order. Maybe you move an item from on to the other.
> What if the second operation fails? Natually you want to roll-back to
> before the operation on the first. That's what J2EE transactions are
> about. See how RDMBS transactions are a different deal in this
> situation?
The problem with this analogy is that in Perl we'd just use exception
handling with automatic rollback on the databases in question (assuming
you don't commit). Throw an exception and be done with it.
You'd probably have to come up with a better scenario where J2EE
transaction management is really required. I've been struggling to grasp
the need for this concept since I attended a Microsoft developer day where
they demo'd their COM based transaction manager for the first time.
But then I'm an old style RDBMS guy. We built multi-million dollar Sybase
systems for large insurance companies. We never needed a transaction
manger. &shrug;
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11700-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Wed Dec 6 01:28:53 2000
Return-Path: <modperl-return-11700-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id BAA41403
for <doom@kzsu.stanford.edu>; Wed, 6 Dec 2000 01:28:52 -0800 (PST)
(envelope-from modperl-return-11700-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 52056 invoked by uid 500); 6 Dec 2000 09:27:26 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 51955 invoked from network); 6 Dec 2000 09:27:24 -0000
Date: Wed, 6 Dec 2000 09:27:24 +0000 (GMT)
From: Matt Sergeant <matt@sergeant.org>
To: "Jeffrey W. Baker" <jwbaker@acm.org>
cc: Perrin Harkins <perrin@primenet.com>, brian moseley <bcm@maz.org>,
mod_perl list <modperl@apache.org>
Subject: RE: mod_perl advocacy project resurrection
In-Reply-To: <Pine.LNX.4.21.0012051759020.12153-100000@heat.dci>
Message-ID: <Pine.LNX.4.30.0012060926070.22298-100000@ted.sergeant.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Tue, 5 Dec 2000, Jeffrey W. Baker wrote:
> I haven't looked at AO or AxKit, but if I can untar either one of them and
> just get to work, that will rule.
You can't, but thats because I believe in the CPAN model - use pre-written
components. I don't believe shipping all those components in AxKit (and
there are a fair number required) is the right solution. Maybe I'm
mistaken.
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
From modperl-return-11701-doom=kzsu.stanford.edu@apache.org Wed Dec 13 14:00:45 2000Delivery-Date: Wed Dec 6 01:36:04 2000
Return-Path: <modperl-return-11701-doom=kzsu.stanford.edu@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by kzsu.stanford.edu (8.9.3/8.9.3) with SMTP id BAA41422
for <doom@kzsu.stanford.edu>; Wed, 6 Dec 2000 01:36:04 -0800 (PST)
(envelope-from modperl-return-11701-doom=kzsu.stanford.edu@apache.org)
Received: (qmail 57643 invoked by uid 500); 6 Dec 2000 09:35:06 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:modperl-help@apache.org>
list-unsubscribe: <mailto:modperl-unsubscribe@apache.org>
list-post: <mailto:modperl@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 57539 invoked from network); 6 Dec 2000 09:35:04 -0000
Date: Wed, 6 Dec 2000 09:35:03 +0000 (GMT)
From: Matt Sergeant <matt@sergeant.org>
To: "Jeffrey W. Baker" <jwbaker@acm.org>
cc: brian moseley <bcm@maz.org>, Perrin Harkins <perrin@primenet.com>,
Matthew Kennedy <mkennedy@hssinc.com>,
"Thomas J. Mather" <tjmather@anidea.com>, <modperl@apache.org>
Subject: Re: mod_perl advocacy project resurrection
In-Reply-To: <Pine.LNX.4.21.0012051814090.12153-100000@heat.dci>
Message-ID: <Pine.LNX.4.30.0012060933540.22298-100000@ted.sergeant.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
On Tue, 5 Dec 2000, Jeffrey W. Baker wrote:
> On Tue, 5 Dec 2000, brian moseley wrote:
>
> > On Tue, 5 Dec 2000, Perrin Harkins wrote:
> >
> > > > Transaction support for your business logic is easy in J2EE. It's not
> > > > clear how you do this in Perl?
> > >
> > > Use an RDBMS.
> >
> > what about transactions that span data sources? yes, this
> > does happen.
>
> Yeah, it *seems* to happen, but it doesn't actually. Any vendor who tells
> you he can do real transactions across data sources is a liar, or using a
> new and improved definition of transaction. You can do it %99.99 of the
> time but that last %.01 is the bitch.
>
> With J2EE you get the complete illusion that you are doing txns across as
> many data sources on as many systems and vendors as you want, but behind
> the illusion there is the nonzero risk that the data is inconsistent. In
> a real transactional system, you can never have inconsistent data.
This thread is suffering from a severe lack of technical information. Can
you go into more technical detail on what that 0.01% is (and is caused
by)?
======
Date: Wed, 06 Dec 2000 01:45:17 -0800
From: Perrin Harkins <perrin@primenet.com>
To: Gunther Birznieks <gunther@extropia.com>
Subject: Re: mod_perl advocacy project resurrection
Gunther Birznieks wrote:
> Has anyone written a Perl IDE in Perl?
There's PerlComposer:
http://perlcomposer.sourceforge.net/
Not too far along yet, from the looks of it.
===
Date: Wed, 6 Dec 2000 10:28:22 +0000 (GMT)
From: Matthew Byng-Maddick <mbm@colondot.net>
To: modperl@apache.org
Subject: Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, brian moseley wrote:
[coldfusion/php]
> how is mason not like this?
It has no point-n-drool authoring tools. This is actually the killer app.
Once this is done, Mason / other templating system of choice gets
catapulted to the forefront....
MBM
--
Matthew Byng-Maddick Home: <mbm@colondot.net> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <matthew@codix.net> +44 7956 613942 (Mobile)
Genius may have its limitations, but stupidity is not thus handicapped.
-- Elbert Hubbard
---------------------------------------------------------------------
To unsubscribe, e-mail: modperl-unsubscribe@apache.org
For additional commands, e-mail: modperl-help@apache.org
===
Subject: Re: mod_perl advocacy project resurrection
From: Matt Sergeant <matt@sergeant.org>
Date: Wed, 6 Dec 2000 12:08:59 +0000 (GMT)
On 6 Dec 2000, David Hodgkinson wrote:
> Matt Sergeant <matt@sergeant.org> writes:
>
> > On Tue, 5 Dec 2000, Jeffrey W. Baker wrote:
> >
> > > I haven't looked at AO or AxKit, but if I can untar either one of them and
> > > just get to work, that will rule.
> >
> > You can't, but thats because I believe in the CPAN model - use pre-written
> > components. I don't believe shipping all those components in AxKit (and
> > there are a fair number required) is the right solution. Maybe I'm
> > mistaken.
>
> Isn't that just a question of getting a Bundle::AxKit together?
>
> Or is that an egg-sucking thing...
Bundles are for when you don't have a dependency tree, which AxKit has.
But the real problem is the non-perl modules. And the fact that AxKit
doesn't seem to work with PHP. And the Apache-expat bug/problem. All these
things make installing AxKit a bit non-trivial.
I quite like the Zope model - a single distribution which just includes
and installs everything you need in a single place. You get python, the
httpd, the database, everything. Of course if you have more complex needs,
like running Zope from within Apache, you need to do some extra work, but
out of the boz Zope gives you a great system that just runs. We could do
that with AxKit - just ship it with Apache, mod_perl, the whole lot. But I
don't think that would appeal to Perl people somehow. Thoughts?
===
Subject: Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
From: Tim Sweetman <tim@aldigital.co.uk>
Date: Wed, 06 Dec 2000 12:10:18 +0000
Matthew Byng-Maddick wrote:
>
> On Tue, 5 Dec 2000, kyle dawkins wrote:
> > * We implement a "mode" under mod_perl, kind of like "use strict", that
> > suddenly forces Perl to behave well from an object-oriented standpoint. By
> > this, I mean taking some of the power away from Perl that causes trouble,
> > like allowing anyone to write instance data on an arbitrary instance of a
> > class...
People are looking at this sort of thing. Damian Conway wrote
Tie::SecureHash and Class::Contract, which may be driving at this sort
of thing.
The latter implements "design by contract", as seen in Eiffel. I read
Damien's paper on it, but haven't used it - there are four things that
put me off:
1. The difficulty of modifying existing classes to work with it
2. The magic of "flyweight scalars", which I haven't yet got my head
around
3. "This code is funky"-type disclaimers scare me.
4. It looks like he just defines "data types" as LIST, ARRAY, the usual
Perl primitives.
This is of limited use, IMHO; being able to _define_ rules for data
types (eg. valid URI;
reference to FooID in table Foo in database bar) would be more
powerful.
(Not that these should all be checked every time, unless you're
implementing a Snail,
but C::C does have the ability to switch checks off, eg, in a live
environment. Though live users
make very thorough testers :-/)
I can see why people want encapsulation, though I've rarely seen
problems due to people violating it. This may be pure luck. *Lack* of
encapsulation may provide clues when you hit something with Data::Dumper
& find out what's going on on the inside.
IMHO, assertions, data type definitions, pre & post conditions are v.
useful things. Define interfaces to methods & functions. This isn't
necessarily the right approach - especially at the beginning of a
project - but it is in some cases, and AFAIK there is little to automate
this stuff available in Perl. Putting up these walls can *really* help
isolate problems.
Eiffel & Class::Contract allow conditions to be *inherited*. So these
approaches work hand-in-hand with OO *and/or* re-use.
===
Subject: Re: mod_perl advocacy project resurrection
From: Robin Berjon <robin@knowscape.com>
Date: Wed, 06 Dec 2000 15:01:46 +0100
At 16:39 05/12/2000 -0800, Perrin Harkins wrote:
>Someone else brought this up with me off the list. Briefly, I said that
>this doesn't usually happen with web sites for performance reasons and
>that major RDBMS vendors offer things like two-phase commit. But no,
>there is no perl transaction service that I know of. You'd have to look
>at interfacing with a commercial TP monitor for that, and those are
>more likely to have hooks already written for Java.
In which case if that's the only part of the app that requires Java (but
the rest is worth doing in Perl) one could simply "use Java;". I haven't
really tested it but I've heard that it works really well.
===
Subject: Re: mod_perl advocacy project resurrection
From: Jim Woodgate <woody@realtime.net>
Date: Wed, 6 Dec 2000 09:32:41 -0600 (CST)
Dave Rolsky writes:
> The problem with them compared to mod_perl is that you don't have access
> to the server internals so you can really only affect the content handling
> phase. Is this the case with Tomcat as well?
I know that you can communicate with the server in the request, it's
not totally stand-alone. But I haven't looked into putting in
handlers in other phases...
===
Subject: Re: mod_perl advocacy project resurrection
From: "Jeffrey W. Baker" <jwbaker@acm.org>
Date: Wed, 06 Dec 2000 08:00:44 -0800 (PST)
On Wed, 6 Dec 2000, Matt Sergeant wrote:
> On Tue, 5 Dec 2000, Jeffrey W. Baker wrote:
>
> > With J2EE you get the complete illusion that you are doing txns across as
> > many data sources on as many systems and vendors as you want, but behind
> > the illusion there is the nonzero risk that the data is inconsistent. In
> > a real transactional system, you can never have inconsistent data.
>
> This thread is suffering from a severe lack of technical information. Can
> you go into more technical detail on what that 0.01% is (and is caused
> by)?
Yup.
Machine A is controlling a transaction across Machine X and Machine Y. A
modifies a row in X and adds a row to Y. A commits X, which succeeds. A
commits Y, which fails.
Now what?
A cannot guarantee a recovery on machine X because there might already be
other transactions in flight on that record in that database. A cannot
just try to put the record back the way it used to be, because now the
commit might fail on X. The data is inconsistent.
The only thing that Machine A can do now is send an email to the DBA
explaining what happened and what was supposed to happen.
"Fucking Hell" says the DBA, under his breath.
===
Subject: Re: mod_perl advocacy project resurrection
From: brian moseley <bcm@maz.org>
Date: Wed, 6 Dec 2000 08:34:18 -0800 (PST)
On Wed, 6 Dec 2000, Matt Sergeant wrote:
> I quite like the Zope model - a single distribution
> which just includes and installs everything you need in
> a single place. You get python, the httpd, the database,
> everything. Of course if you have more complex needs,
> like running Zope from within Apache, you need to do
> some extra work, but out of the boz Zope gives you a
> great system that just runs. We could do that with AxKit
> - just ship it with Apache, mod_perl, the whole lot. But
> I don't think that would appeal to Perl people somehow.
> Thoughts?
this is how we ship our products internally at cpth. we
build perl, apache, 100 or so modules, and ~150 registry
scripts. then we rpm the whole thing up. the operations team
just has to:
rpm -i && /usr/local/webmail/current/bin/wmctl start.
doing something like that doesn't play nice with the os
vendor distributions really, but some people might like it.
another option would be to use autoconf. wrap a configure
script around your entire set of components. allow it to
find and use whichever ones you've already got installed.
have it build and install whatever you don't already have.
not very tough. also not very portable to windows.
===
Subject: Re: mod_perl advocacy project resurrection
From: brian moseley <bcm@maz.org>
Date: Wed, 6 Dec 2000 08:35:33 -0800 (PST)
On Wed, 6 Dec 2000, Jim Woodgate wrote:
> I know that you can communicate with the server in the
> request, it's not totally stand-alone. But I haven't
> looked into putting in handlers in other phases...
i believe with mod_jk there is a callback model, yes. but
given tomcat's valve architecture, i don't see much need to
call back into apache at all.
===
Subject: RE: mod_perl advocacy project resurrection
From: Matt Sergeant <matt@sergeant.org>
Date: Wed, 6 Dec 2000 16:33:58 +0000 (GMT)
On Wed, 6 Dec 2000, brian moseley wrote:
> On Wed, 6 Dec 2000, Matt Sergeant wrote:
>
> > You can't, but thats because I believe in the CPAN model
> > - use pre-written components. I don't believe shipping
> > all those components in AxKit (and there are a fair
> > number required) is the right solution. Maybe I'm
> > mistaken.
>
> that's why Bundle::AO is nice.
What does Bundle::AO give you that setting PREREQ_PM correctly wouldn't?
> it's stubborn adherence to models like this, tho, that keeps
> us from making generational advances rather than incremental
> ones.
Agreed... I *do* wish that more perlers would be open to binary modules -
the Activestate PPM model. While there were regularly problems with PPM,
the vast majority of module installations were incredibly trivial.
===
Subject: Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
From: Matthew Byng-Maddick <mbm@colondot.net>
Date: Wed, 6 Dec 2000 10:52:53 +0000 (GMT)
On Tue, 5 Dec 2000, kyle dawkins wrote:
[1. two types of developer]
agreed.
[2. Perl4 / Perl5 ]
This is also true. Although a lot of "Perl programmers" haven't got a clue
about the object orientation stuff in Perl5 either. On the other side of
the coin, too many people are jumping on the "It's object oriented, it
must be reusable" and "The only way to solve problems is using objects"
bandwagons. Java and C++ both play to these. And unfortunately they've
convinced management, in general. Plus, big corporates like to deal with
corporates - Java is defined by Sun, a corporate. This is always going to
make our life hard...
> 3. Installation/setup
> Ok, so if you have Linux, it's a piece of cake... download all the sources,
OK. but s/Linux/a UNIX or UNIX-alike/g.
> follow the README's, and go. But what if you don't have Linux? Or you
> aren't root, and what if you need access to httpd.conf to keep changing
Then you don't necessarily do it on port 80. This is the only reason you
need to be root.
> stuff? And developers are going to need to cycle the server all the time, so
> they need the ability to do that, too... it's definitely a weak point. I can
> install any one of the Java-based web application frameworks and be
> developing immediately.
I disagree. The webserver stuff still needs to be run as root, or you run
it on a different port. Although I would also suggest having a look at
userv (http://www.chiark.greenend.org.uk/~ian/userv/), although there are
some security holes opened up by using mod_perl.
> 4. Isolation
> A lot of mod_perl projects (or even Perl projects in general) tend to be
> one-person shows... maybe I'm wrong, and I'd love it if people could correct
> me! But in my observation, we have a lot of programmers working in
> isolation. This is bad.
<plug>http://codix.net/</plug>.
> 5. Foundation libraries
> Because of the open nature of the CPAN community, there are a lot of great
> modules floating around out there. However, there is no real API consistency
> in them, and this will cause newcomers to Perl a fair amount of trouble.
> Moreover, we're not going to get anywhere in the enterprise if people insist
> on using HTML templating systems that allow the embedding of code within
> HTML. It's straight up and down a total disaster and no right-minded
> software architect would ever consider it.
Agreed.
> 6. Engineering
> The Perl community is made up of a truly eclectic group of people, which is
> an amazing strength. However, it's also an amazing weakness: I get the
> impression that very few programmers in the Perl community spend a lot of
> time *reading* books on software engineering and techniques thereof... and
I'm not convinced about this. Although from my limited experience, I'm not
very fond of them....
> that lack of knowledge tends to bleed over into a lot of code out there. We
> have a HUGE problem in the community of the "coder superstar" mentality...
yup.
> which is very dangerous. Perl allows far too many tricks, and often code
> ends up totally unmaintainable and unreadable because some coding yahoo put
> in some glory-code. It happens in many languages, true, but Perl is the
> ideal environment for it.
Not necessarily. You can get coder superstars who write maintainable and
understandable code.
> --> SO <--
> I hope you guys can give these points some thought. I could be "smoking
> grass" but I think I'm on target on most of my points and I'd love to hear
> what you guys think too. In the meantime, here are some ideas that might go
> down well (or not!):
Not entirely.
> * We implement a "mode" under mod_perl, kind of like "use strict", that
> suddenly forces Perl to behave well from an object-oriented standpoint. By
> this, I mean taking some of the power away from Perl that causes trouble,
> like allowing anyone to write instance data on an arbitrary instance of a
> class...
No. no no no. Forcing perl to behave as "Object oriented" is entirely the
wrong thing. This is why Java sucks so much. "Everything is an object"
(excepting, obviously, the language primitives). Perl is nice because you
can write it functionally or object oriented depending on the problem
you're trying to solve. Also this functionality is more core Perl than
mod_perl.
> * We "homogenise" some foundation classes. This means we create a *suite* of
> classes that have consistent API, are designed together as a framework, and
> are easy to learn
I think you need to get out of the "object-oriented-only" mentality. But
yes, sort of, agreed.
> * We need to drop-kick DBI out of the park... it's not that it's bad (it's
> actually great... kudos to the DBI crew) but kind of the opposite; it's so
> easy to use that most people don't think beyond it. How many of you have
> ever thought about implementing an Object-Relational middleware layer using
> mod_perl? We could create a set of generic OR classes as part of our
> foundation framework.
DBI is actually quite a hassle to use sensibly, and I've got my own
library functions that call the DBI ones, and return errors in a way that
is consistent. I also have the run object open DB connections. (YATS)
<another plug>http://codix.net/ASPerl/</plug>.
===
Subject: RE: mod_perl advocacy project resurrection
From: brian moseley <bcm@maz.org>
Date: Wed, 6 Dec 2000 08:59:02 -0800 (PST)
On Wed, 6 Dec 2000, Matt Sergeant wrote:
> What does Bundle::AO give you that setting PREREQ_PM
> correctly wouldn't?
i don't know :) i use them both.
===
Subject: RE: mod_perl advocacy project resurrection
From: "Bruce W. Hoylman" <bhoylma@qwest.com>
Date: Wed, 6 Dec 2000 11:17:25 -0700
This debate has really hit some hot buttons. I love reading the
exchanges as there are clearly some personal philosophies at work here.
Ain't it great!
>>>>> "Michael" == Michael Robinton <michael@bizsystems.com> writes:
Michael> Give a man a dump truck full of leggos, motors and gears
Michael> and you can build some really interesting stuff, give man
Michael> an end mill or a lathe and he can build a rocket ship to
Michael> the moon. You figure out which one is Weblogic and which
Michael> one is Apache-modperl :-)
Doubtful.
In my experience, these so-called enterprise solutions are just that
... a huge lathe, or whatever an end mill is. Their solution to even
the most minute problem is to throw huge - I mean huge - application
piece parts at it, hoping to bury it in the wizard technology of the
moment. There is no other solution. You get it all or you get none of
it. Or if you only want a part of the bulk, you still must sift through
a mountain of installed crap. "What do you mean I need 1GB of disk and
500 MB of memory just to get an internet-enabled report queue manager?"
Now maybe some feel better with a large enterprise application server or
whatever staring over one's shoulder, but I prefer to build my solution
in a way that I get only what I need. The rest can be called upon,
installed if you will, when it is deemed necessary (by me, or by the
needs of the environment), but otherwise only the necessary parts are
present and in play. And I can determine what is necessary and when,
not the vendor supplying the solution-of-all-solutions.
Apache/mod_perl has enabled my team and I to craft finely detailed
modules that I can apply to specific problems in my intranet
environment. I can bring to the battle one, some, or all of mod_perl's
intrinsics coupled with the vast CPAN, tightly woven with modules of
An enterprise-size solution is rarely a viable answer to an
enterprise-size problem.
===
Subject: Re: RFC: mod_perl advocacy project resurrection
From: Jim Winstead <jimw@trainedmonkey.com>
Date: Wed, 6 Dec 2000 13:19:45 -0500
On Dec 05, Greg Cope wrote:
> > But, you all know that php pretty much takes over. Why? For two reasons:
> > 1) initial corporate pushing (press/ads)
> > 2) once well known, the word of the mouth does the rest.
>
> Well go back 2 / 2 1/2 years and PHP was little known.
what is even funnier is that if you go back that far and look at
the php mailing lists back then, you'll find the exact same
conversations. :)
how did php become so popular? so many hosting companies offered
it as part of their hosting. fortunately for php, it targets a bit
more of a niche (generating dynamic content) than mod_perl does
(writing apache modules in perl) so offering it as part of a hosting
package on shared servers is quite a bit easier.
(of course, this only addresses scaling to a breadth of users, not
scaling into the enterprise area. that just requires real marketing
and hype.)
===
Subject: Re: mod_perl advocacy project resurrection
From: Ask Bjoern Hansen <ask@valueclick.com>
Date: Wed, 6 Dec 2000 10:38:10 -0800 (PST)
On Wed, 6 Dec 2000, brian moseley wrote:
[...]
> this is how we ship our products internally at cpth. we
> build perl, apache, 100 or so modules, and ~150 registry
> scripts. then we rpm the whole thing up. the operations team
> just has to:
>
> rpm -i && /usr/local/webmail/current/bin/wmctl start.
that's what we do at ValueClick too, (except using a tiny script
that configures a perforce view and does a perforce sync instead of
the rpm).
> doing something like that doesn't play nice with the os
> vendor distributions really, but some people might like it.
for applications that are complex enough[tm] it makes sense to
install your own perl, apache, everything. For everything else it's
bloat and just a waste.
> another option would be to use autoconf. wrap a configure
> script around your entire set of components. allow it to
> find and use whichever ones you've already got installed.
> have it build and install whatever you don't already have.
> not very tough. also not very portable to windows.
and doesn't work (or get's complex fast) if it needs, say,
/usr/bin/perl but with -Duselargefiles and the already installed
stuff needs it without.
===
Subject: Re: mod_perl advocacy project resurrection
From: barries <barries@slaysys.com>
Date: Wed, 6 Dec 2000 14:00:49 -0500
On Wed, Dec 06, 2000 at 08:00:44AM -0800, Jeffrey W. Baker wrote:
> On Wed, 6 Dec 2000, Matt Sergeant wrote:
>
> > On Tue, 5 Dec 2000, Jeffrey W. Baker wrote:
> >
> > > With J2EE you get the complete illusion that you are doing txns across as
> > > many data sources on as many systems and vendors as you want, but behind
> > > the illusion there is the nonzero risk that the data is inconsistent. In
> > > a real transactional system, you can never have inconsistent data.
> >
> > This thread is suffering from a severe lack of technical information. Can
> > you go into more technical detail on what that 0.01% is (and is caused
> > by)?
>
> Yup.
>
> Machine A is controlling a transaction across Machine X and Machine Y. A
> modifies a row in X and adds a row to Y. A commits X, which succeeds. A
> commits Y, which fails.
>
> Now what?
Isn't that what using a two-phased commit on X and Y is supposed to do:
allow you to back out of the half-committed transaction on X?
===
Subject: Re: mod_perl advocacy project resurrection
From: William.P.McGonigle@artoo.hitchcock.org (William P. McGonigle)
Date: 06 Dec 2000 14:11:19 EST
Jeffrey W. Baker" wrote:
Yup.
Machine A is controlling a transaction across Machine X and Machine Y. A
modifies a row in X and adds a row to Y. A commits X, which succeeds. A
commits Y, which fails.
Now what?
A cannot guarantee a recovery on machine X because there might already be
other transactions in flight on that record in that database. A cannot
just try to put the record back the way it used to be, because now the
commit might fail on X. The data is inconsistent.
--- end of quote ---
You can buy a solution to that. High-priced java
application servers like iPlanet's call this "two-phase
commit" and hide it behind JTA (using IBM's Encina engine in
this case). For only $35k per CPU.
There must be a CPAN module for it. ;)
===
Subject: Re: mod_perl advocacy project resurrection
From: barries <barries@slaysys.com>
Date: Wed, 6 Dec 2000 14:17:02 -0500
On Wed, Dec 06, 2000 at 04:55:37PM +0800, Gunther Birznieks wrote:
>
> Has anyone written a Perl IDE in Perl?
Tom Christiansen wrote an IDE-like lash-up of vi and perl, IIRC, but I
don't recall the specifics and I can't find in on-web right now. You
might search the perl5-porters archives for mention of it. It certainly
doesn't have the forms-based programming model that many people mean
when they say "IDE", but under Unix, lots of editors have the
compile-execute-tweak cycle semi-automated (which is what I think of
when I hear "IDE"). Some could have GUId for the perl debugger, I don't
know. There are various such GUI front ends floating around, FWIW.
Codewrite and NEdit are pretty good alternatives on Windows that might
qualify as IDEs, depending on your definition. (NEdit is very
multiplatform, too) if that's where you code Perl.
===
Subject: Re: RFC: mod_perl advocacy project resurrection (and a
From: Robin Berjon <robin@knowscape.com>
Date: Wed, 06 Dec 2000 20:55:55 +0100
At 14:07 06/12/2000 -0500, kyle dawkins wrote:
>Ok, you're missing my point but that's partially my fault for not explaining.
> First, let me agree: Java's "everything is an object" mentality sucks
>balls. And yes, Perl's duality of functional/OO is really nice. Taking that
>away is not what I am advocating... I think there should be the *option* in
>Perl to disable certain features that make Perl a dangerous language for OO
>development. First and foremost, the lack of true encapsulation is
>disastrous. There is no concept of private data because instance data is
>stored in a blessed hash (typically) that's open wide to the world. It makes
>it tough to create a true interface/implementation dichotomy that is
>important in the OO world.
That's because of the way most people implement their classes. Perl does
have a concept of private date (although it's not built into the language
as that) and it's actually fairly easy to get that. OO Programming with
Perl by Damian Conway has plenty of example demonstrating that. I also have
an inheritable Class::ArrayBased somewhere on my disk that provides a
framework for array based objects. Admittedly it's encapsulation through
obscurity (so to say) but people that understand how it works will probably
respect the encapsulation, while those that don't will fail to access the
content as a hashref.
===
Subject: Re: mod_perl advocacy project resurrection
From: Paul <ydbxmhc@yahoo.com>
Date: Wed, 6 Dec 2000 11:59:34 -0800 (PST)
Chris Winters <chris@cwinters.com> wrote:
[...]
> 'Java' and 'open-source' are not mutually exclusive :-)
Hallelujah!
I still prefer Perl, but this is news to me, and GOOD news! =o)
[...]
> And the perception out there, unlike with mod_perl, is that you don't
> need to be a wizard to build such applications. Maybe that's because
> there are more books, maybe that's because of the marketing machine,
> maybe that's because IDEs will give you some hand-holding along the
> way -- I dunno.
I think a lot of that convenience is built into the Java
straightjacket, but I will admit that, in a broad production system,
I'd probably be more willing to wear that straightjacket to make sure I
didn't bring the server down. Java is built for safety. I may not
like it, but it's valid. I just prefer Perl.
Still, (mod_)perl advocacy should provide more and better (mod_)perl
tools. Both languages are evolving; Larry's putting Unicode and
Threads into the next Perl, right? Java regex's are improving, yes? We
advocate (I will still support Java and Python and x,y,&z, but mostly
Perl) to build our resource base. A bigger, better, cleaner, easier
pool of tools means a bigger, better, cleaner, easier language, and the
cycle goes 'round.
===
Subject: Re: mod_perl advocacy project resurrection
From: mkennedy@hssinc.com (Matthew Kennedy)
Date: Wed, 06 Dec 2000 14:31:28 -0600
brian moseley wrote:
>
> On Wed, 6 Dec 2000, Gunther Birznieks wrote:
>
> > Has anyone written a Perl IDE in Perl?
>
> i goofed around with a class browser/code generator a while
> back, but i lost interest. as i recall, #perl laughed at me
> when i suggested it :)
ActiveState has built an Perl/Python IDE out of Mozilla:
http://www.activestate.com/Products/Komodo/index.html
===
Subject: Re: mod_perl advocacy project resurrection
From: Ged Haywood <ged@jubileegroup.co.uk>
Date: Wed, 6 Dec 2000 20:29:11 +0000 (GMT)
Hi there,
This isn't a silly question. At least I hope it isn't.
On Wed, 6 Dec 2000, Jeffrey W. Baker wrote:
[snip,snip]
> A modifies a row in X and adds a row to Y. A commits X, which succeeds.
> A commits Y, which fails.
>
> The only thing that Machine A can do now is send an email to the DBA
>
> "..." says the DBA,
Given that it's designed to fail sooner or later, are there good
reasons why someone would put together a system in that way?
===
Subject: Re: mod_perl advocacy project resurrection
From: brian moseley <bcm@maz.org>
Date: Wed, 6 Dec 2000 12:39:52 -0800 (PST)
On Wed, 6 Dec 2000, Matthew Kennedy wrote:
> ActiveState has built an Perl/Python IDE out of Mozilla:
>
> http://www.activestate.com/Products/Komodo/index.html
too bad it's windows only :/
===
Subject: Re: mod_perl advocacy project resurrection
From: mkennedy@hssinc.com (Matthew Kennedy)
Date: Wed, 06 Dec 2000 15:00:12 -0600
Bruce W. Hoylman" wrote:
<snip>
> In my experience, these so-called enterprise solutions are just that
> ... a huge lathe, or whatever an end mill is. Their solution to even
> the most minute problem is to throw huge - I mean huge - application
> piece parts at it, hoping to bury it in the wizard technology of the
> moment. There is no other solution. You get it all or you get none of
> it. Or if you only want a part of the bulk, you still must sift through
> a mountain of installed crap. "What do you mean I need 1GB of disk and
> 500 MB of memory just to get an internet-enabled report queue manager?"
I don't know where you got the 1GB disk requirement from? Even
Weblogic's download is only 43Mb, jBoss' is about 6Mb. The Java Platform
is somewhere between that. Your compiled enterprise app might only be
300Kb (and not just a "report queue manager"). And 500Mb of memory?
That's tuppence in the server world anyway.
J2EE is such a joy to work with in these class of problems which require
a middle tier. The APIs are clearly defined and standardized, every
object has a consitent feel, low level issues such as socket
communications and threading is handled for you. It leaves the developer
free to actually code toward the solution.
> Now maybe some feel better with a large enterprise application server or
> whatever staring over one's shoulder, but I prefer to build my solution
> in a way that I get only what I need. The rest can be called upon,
If you think you can hack out a solution for those class of problems
from CPAN, then good for you. I'm sure you can in some cases. I think
mod_perl has done an excellent job of conquering the the two-teir
web-based problems. I love tools such as Mason and Apache::ASP which
ride on mod_perl. Perl-DBI is an excellent advancement for Perl in
general also.
I think it's exciting to think what an n-tier framework in Perl might
look like. IMHO, it should be more than just the outgrowth of CPAN's
contents.
<snip>
> An enterprise-size solution is rarely a viable answer to an
> enterprise-size problem.
Sounds almost like you're talking about "enterprise" being a "company"?
I know you can't be though... right?
===
Subject: Re: mod_perl advocacy project resurrection
From: mkennedy@hssinc.com (Matthew Kennedy)
Date: Thu, 07 Dec 2000 09:37:52 -0600
Bruce W. Hoylman" wrote:
> >>>>> "Matthew" == Matthew Kennedy <mkennedy@hssinc.com> writes:
<snip>
> Matthew> compiled enterprise app might only be 300Kb (and not just a
> Matthew> "report queue manager"). And 500Mb of memory? That's
> Matthew> tuppence in the server world anyway.
>
> This happens to be minimum numbers for working with a particular
> Application Server marketed by a well-known database vendor by the name
> of Oracle Corp.
;-) Could someone actually be using Oracle's Application Server!
> Matthew> I think it's exciting to think what an n-tier framework in
> Matthew> Perl might look like. IMHO, it should be more than just the
> Matthew> outgrowth of CPAN's contents.
>
> I agree, but I should be able to expand and contract this middle tier
> monster in a very similiar fashion. Hey, I want some functionality, get
> it, configure it, install use it, derive from it, whatever. On the
> other hand, if I don't want, I can wipe it out without horking up the
> entire system.
I agree with this. A pluggable architecture is nice. Incidentally,
that's what the J2EE platform offers as well. For instance; I don't have
to use JavaMail with EJB, or the Java Messaging System with EJB, or even
JDBC with EJB either etc. Those modules would not necessarily have to be
loaded into a JVM in order for me to use the rest of the framework.
Sounds to me that this would not be too hard to do in a Perl context
either.
I think in general the work gone into J2EE's specification and rationale
might be an excellent requirements model for a Perl n-tier equivalent.
===
Subject: Re: mod_perl advocacy project resurrection
From: mkennedy@hssinc.com (Matthew Kennedy)
Date: Thu, 07 Dec 2000 22:52:10 -0600
Eustace, Glen" wrote:
>
<snip>
> going to go the Java way, the reasons have all been stated in this thread
> before; Market hype, its an expensive solution so it must be good, its a
> cool new technology, you can't get good perl programmers, its what is being
> used by everyone else, we don't understand mod_perl ( they don't understand
> the java solution either ), we can buy the business logic we don't have to
> build it ...
I've developed in both (mod_perl indirectly via Apache::ASP) and I say
there really is more than "market hype" to the Java enterprise
technologies. There is good rationale behind it's design. Some smart
engineering has gone into the J2EE framework. I recommend the
specification documents for excellent examples and explanation (it's not
your everyday dry spec document). If I were developing an application
which fit well into the two-tier model however, a mod_perl based plan
would be my first preference -- development time is shorter than
JSP/Servlet and maintainability is _at_least_ comparible.
Myth: J2EE is an expensive solution. This is simply wrong. There are at
least two open source EJB servers and containers (http://www.jboss.org
being my favourite), for the web side there is at least Tomcat and Jetty
(both open source) and a bunch of web web publishing frameworks
(XSP/Cocoon, Enhydra etc.) to chose from -- all free.
> I like the perl/mod_perl solution, it works well for me, I believe it is
> also an appropriate technology for solving enterprise problems. The biggest
> hurdle we have faced in trying to get it considered has been market
I like mod_perl solutions too. There are however, problems which are
better solved by an enterprise suite. Java of which provides the most
simple by far.
===
Subject: Re: mod_perl advocacy project resurrection
From: Jim Woodgate <woody@realtime.net>
Date: Fri, 8 Dec 2000 09:00:59 -0600 (CST)
Matthew Kennedy writes:
> If I were developing an application
> which fit well into the two-tier model however, a mod_perl based plan
> would be my first preference -- development time is shorter than
> JSP/Servlet and maintainability is _at_least_ comparible.
I would add that the "java is easier to maintain" issue is IMHO the
biggest myth of java. I've seen a bunch of over-engineered java the
past couple of years and when something goes wrong, be afraid! :)
===
To: <spam@vancouver.yi.org>
From: Gunther Birznieks <gunther@extropia.com>
Subject: Re: mod_perl advocacy project resurrection
Date: Sun, 17 Dec 2000 23:27:25 +0800
At 01:45 PM 12/10/00 -0800, spam@vancouver.yi.org wrote:
>On Sun, 10 Dec 2000, Gunther Birznieks wrote:
>[much stuff snipped]
> >
> > >Things I would never even try with java:
> > >
> > >1) Talking any client/server protocol other than URLs. The perl
> > >mail/ftp modules are so easy to use and they work great. I don't even
> > >want to think about writing to syslogd from inside java... :)
> >
> > There have been public domain libraries to write to syslogd in Java for a
> > long time. The only problem with Java in this regard is that there is no
> > CPAN. But if you search on the net, you can usually find something in Java
> > that has the equivalent to a CPAN module that deals with networking as
> Java
> > makes networking quite easy.
>
>Sun was not onto community thing anyways, they're corporation, and giving
>up a control something they spend money on, will give chills to the
>managing types that are not for the OS thing.
>No CPAN is an oversight for the Java people, but really how can they
>implement it? Java runs across many platforms and VMs for it are written
>by many companies. If one dares to do something like that.
>For one they have to figure out how not to breach security of systems
>where people will be installing custom java classes. Java like windows2000
>was touted for the security and CPAN like thing will bring some bugs and
>holes into the frame work I am almost sure.
Well, with Java, because the modules are not compiled, you don't really
need CPAN in the sense of a perl Makefile.pl style. I was really referring
to a central repository of code period.
There are Java "directories" but nothing like CPAN. I am disappointed at
things like gamelan because whenever I want to find something (Ill pick on
Gamelan specifically here)
(A) Gamelan is slow
(B) It's really hard to search on package categories
(C) The code points to someone else's website... so it's at the whim of the
author still being around. Worse, 75% of the links seem to lead to
commercial or shareware sites that gladly take your money if you want to
use the class library.
I don't think that a CPAN for Java is a security issue any more so than
CPAN. It just would be nice to at least have a searchable directory of open
source Java libraries.
As for SUN not wanting a CPAN, I dont think thats true. They would love to
see people writing more open source on top of Java. That doesn't mean that
Java itself would be distributed there, but certainly non JDK originated
stuff could go into a central directory.
===