Re: Smart installing (Re: mod_perl advocacy project resurrection)

[Aaron E. Ross]

at a time earlier than now, Dave Rolsky wrote:
> On Wed, 6 Dec 2000, brian moseley wrote:
> 
> But I'd also like to point out, as Matt Sergeant said, this stuff is
> _really_ hard, and not very glamorous.  I would've done much less of it

 while the install and auto configure part is not very glamorous, the 
 possibility of being able to untar one package to get mod_perl w/ persistent 
 db connections, transaction management, data relational modeling/objects and 
 a nice templating/servlet engine is very glamorous! you could be a folk hero!

 honestly it seems like a pretty worthwhile project to me. basically, what is
 missing is (cough! cough!) simply a lot of hard work. 
 
 except for transaction management, which is apparently of questionable value, 
 all the pieces exist, right?

   database abstraction and connection pooling => DBI
   session management  => Apache::Session
   load balancing  => mod_backhand??
   data relational mapping => Tangram or Alzabo
   templates or whatever you want to call them => HTML::Embperl/Mason/TemplateToolkit
   ide => pick an editor with a few hooks to call make, install and restart

 granted this may not get us everything, but if we could package up the stuff
 we all use over and over again, wouldn't that get us pretty far? 

 Aaron

 I'm willing to contribute time to this project if given some input on how 
 to proceed.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

shared mem [was: mod_perl advocacy project resurrection]

[Paul]

--- Jim Woodgate <[EMAIL PROTECTED]> wrote:
[...]
> 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.

Is there no Apache::SharedMemory (or some such)?
If not, does anyone think it would be worth the time for someone (like
me) to sit down and write it?  (Couldn't it be done?)

The parent process could declare a shared memory segment at boot time.
Each child's init could spawn a shared memory interface object.
Wouldn't that allow for some resource pooling to be cleaner?
How would that interact with per-child namespaces (if at all)?

Is there a reasonably safe and useful way for one process to open a
resource (like a DBM or database handle) and then expose it to another
process through a shared memory segment?

__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[brian moseley]

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 :/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Ged Haywood]

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?

73,
Ged.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Matthew Kennedy]

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

-- 
Matthew Kennedy
Opus Healthcare Solutions, Inc.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [entirely OT :o] Version 0.3? [Was: mod_perl advocacy project resurrection]

[J. J. Horner]

On Wed, Dec 06, 2000 at 11:14:46AM -0800, Paul wrote:
> --- Perrin Harkins <[EMAIL PROTECTED]> wrote:
> > > 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. 
> 
> Where can *I* get that upgrade? =o)
> 

I think you will need to install Apache::KissMyRedEye to make that module work.

JJ
-- 
J. J. Horner
[EMAIL PROTECTED]

"The people who vote decide nothing.
The people who count the vote decide everything."
- Josef Stalin

"The tree of liberty must be watered periodically with the 
blood of tyrants and patriots alike. ... Resistance to tyrants
is obedience to God."
- Thomas Jefferson

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Paul]

--- Chris Winters <[EMAIL PROTECTED]> 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.

__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection (and a proposal!)

[Robin Berjon]

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.

-- robin b.
Make it idiot proof and someone will make a better idiot. 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[barries]

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.

- Barrie

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[entirely OT :o] Version 0.3? [Was: mod_perl advocacy project resurrection]

[Paul]

--- Perrin Harkins <[EMAIL PROTECTED]> wrote:
> > 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. 

Where can *I* get that upgrade? =o)


__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[William P. McGonigle]

--- "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. ;)

-Bill

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Smart installing (Re: mod_perl advocacy project resurrection)

[Dave Rolsky]

On Wed, 6 Dec 2000, brian moseley wrote:

> 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.

Perhaps part of this is that we simply need smarter configure/install
methods.  There are many limitations imposed by the Perl MakeMaker stuff,
a lot of which I have run up against trying to get Alzabo (which is part
modules, part mason components, and also needs a place on disk to store
info) tested and installed properly.  I've also dealt with this on another
app I'm working on (currently under NDA) that requires a bunch of modules,
a set of tables in a database, mod_perl, etc.

I keep meaning to look into cons.  Perhaps that is the way to go?

For example, perhaps all modules should check for the prerequisites on
their own and attempt to use CPAN to fetch them if they can't find them.
That works great if the person installing has already config'd the CPAN
module but if not it'll ask you a lot of questions, which may be annoying.

Is there a better way?

I'm pretty sure there is.  The problem is right now all my solutions are
pretty much ad hoc (package MY up the wazoo).  It would be nice to get
something a lot smarter going.

This is semi-offtopic but does relate the 'untar and go' concept.  I don't
think that that is all that likely.  But 'untar, run configure, answer
some questions, and go'.  That would be a great goal, as opposed to
'untar, try to install, realize you're missing five pieces, install those
pieces, try to install, realize you missed something else, install it, try
to install once again, get it installed, tweak three config files,
manually start up the server with the right switches, and go!'

But I'd also like to point out, as Matt Sergeant said, this stuff is
_really_ hard, and not very glamorous.  I would've done much less of it
except for the fact that I'm being paid to do it for the above-mentioned
NDA'd project.  I do it for Alzabo because I feel strongly enough about
its potential to try to make it more seemless than your average Perl
module/app.


-dave

/*==
www.urth.org
We await the New Sun
==*/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[OT] shmget? [Was: mod_perl advocacy project resurrection]

[Paul]

--- Gunther Birznieks <[EMAIL PROTECTED]> wrote:
[re: Java]
> 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.

Can't say I've looked, but has no one put a nice class wrapper around
shared memory in Perl?



__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[barries]

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?

- Barrie

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection (and a proposal!)

[kyle dawkins]

On Wed, 06 Dec 2000 05:52, Matthew Byng-Maddick wrote:
> > 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

Hmmm, I'm not sure if you're talking about the programmers or the books.  Ha. 
 But seriously, I lose a lot of respect for people who don't continually 
study software engineering yet call themselves developers.  Our craft is 
constantly evolving, and to ignore the material that's available to us to 
learn new techniques is completely irresponsible and it leads to some of the 
problems that we are bemoaning in this very thread.  

> > 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.

OK, terminology problem... I wouldn't call them "coder superstars" *if* they 
write maintainable and understandable code.  Perhaps I should have called 
them "glory coders" instead.  You're totally right, there are plenty of great 
coders out there who conform to coding standards and don't write tricky code. 
 But what I mean is that there is an abundance of glory-coders in the Perl 
community because, in a way, the community encourages it.  That doesn't fly 
in a large-scale project and greatly reduces the chances of mod_perl being 
adopted in the enterprise (IMHO).


> > * 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.

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.

> > * 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.

U, remember, this thread is about mod_perl advocacy.  In my mind, we will 
have huge problems encouraging enterprise adoption of mod_perl without some 
fundamental changes.  No enterprise in its right mind would choose a platform 
that is not OO for any large project these days.  Regardless of whether you 
like this or not (and I can tell that you don't), it's the truth... you said 
it yourself. In order to fight the Java juggernaut, we have to beat them at 
their own game.  Perl has so many advantages over Java that that shouldn't be 
a problem, yet it is.  Primarily, it's one of perception... Perl is a 
scripter's language, Perl is for hackers, Perl is great for sysadmin tasks... 
but it's also a technical one.  Java has a set of foundation classes that 
everyone uses.  They suck festering balls, but they're there. We can learn 
from that and build a set of consistent classes that allow developers to 
build web *apps*, not a shitload of scripts that kinda work together as 
glorified CGI, which is what we get all too often now.

Yes, Java is a sorely broken language, but it's being adopted, partially 
because of Sun's hype but also because it offers enterprise developers real 
ways to encapsulate their business logic proper

Re: mod_perl advocacy project resurrection

[Ask Bjoern Hansen]

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.


 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Jim Winstead]

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.)

jim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[Bruce W. Hoylman]

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 <[EMAIL PROTECTED]> 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.



Peace.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[brian moseley]

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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[Matt Sergeant]

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.

-- 


/||** 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[brian moseley]

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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[brian moseley]

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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[brian moseley]

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.

it's stubborn adherence to models like this, tho, that keeps
us from making generational advances rather than incremental
ones.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[brian moseley]

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 :)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Jeffrey W. Baker]

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.

-jwb


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection (and a proposal!)

[Buddy Lee Haystack]

I've always considered mod_perl similar to an artist's canvas, while Java is more like 
a craftsman's tool kit.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Stephen A. Cochran]

I've been following along with this thread with interest, expecially since I'm
new to the mod_perl list and community (thanks for all the help so far!). I
thought you might be interesed in a 'mod_perl newbie' opinion.

Recently I was handed an online event calendar running under CGI and asked to
get it to run under mod_perl to speed it up. I'm comfortable with perl, but by
no means a guru. And this was the first time using mod_perl. In the past I've
used several products which might be considered competitors to mod_perl: Web
Objects and Cold Fusion. CF was horrible, I'm glad I didn't have to work with it
for long. WO was very nice to work with, and it had all the ecommerce and
transation logic needed to build a enterprise web application quickly. (None of
my work has been in ecommerce, instead in the medical industry (patient data,
lab results, etc) which has many of the same requirements). 


Installing: 
I've installed mod_perl twice in the last month. The first time was on Solaris
and was quite painless. The second time was on RH 7.0, and was fairly painful.
Took most of a day of futzing around to finally get it installed and working. I
ran into two problems, first the unrecognized version of apache 1.3.14, and
second when I had downgraded to 1.3.12 the new auto-configure part of apache was
bypassing the standard Configuration file which mod_perl had inserted itself
into, so Apache was building itself without mod_perl.

As several others have said here, there is work which could be done in this
area. My suggestions would be:
- easier install in general (big red button approach is always nice)
- make it easier (clear instructions too) on how to configure apache with
mod_perl and other modules. The current 'big red button' only works if you have
no other modules or already have them configured.
- Instructions written for someone who knows nothing about mod_perl, and
possible very little about unix. This is a general problem for all open source
projects. With today's IT shortage, more and more sys admins are just power
users who were promoted or sucked into duties because someone else left. If you
want to catch their eye, make sure you talk at their level. I realize this can
be a pain in you know where, and it's something that as you look to advocate you
need to think about. "Do we want to target everyone, or should there be a
minimum level or aptitude before we recommend someone installs this?" Anyone can
walk into Staples these days and install Linux. If they have a decent
distribution installing everything is easy. But even without a package manager
like RH, apache is usually very painless to install. I know a number of
non-profits who just have competent users maintaining a Linux server with
apache, because for the most part it's trouble free. At worst they might have to
restart the server.


Technical Issues:
The second problem I see with mod_perl is a technical one. Because of the design
of mod_perl, debugging problems can be fairly involved. Is the problem my code?
Or is it apache, or maybe mod_perl? Could even be perl for that matter. Take for
example the problem I ran into recently. (Please don't take this as a rant just
because I had problems, I'm happy with mod_perl. But I'm fairly capable around
unix and compiling, instead imagine this happening to someone who wasn't that
comfortable.)

The event calendar works great under CGI, so I try it under mod_perl. It was
written to work under mod_perl by a better perl programmer that I'll ever be
(Jon Howell of Faq-o-matic fame) and is very well designed. It even worked under
mod_perl with some minor changes like supplying the user/pass to the database
since it wasn't running under cgiwrap any longer. And it worked! But only 90% of
the time.

The other 10% of the time, the client received no data, and the page generated
by the script ended up in the apache log. After cleaning up one implicit
database handle destruction warning the problem persisted, and I began to
attempt to discover where the connection was being closed. So I did what any
lazy programmer does, I added some print statements to send a note to STDERR.
While these all showed up when the program worked correctly, when problem
occured, the prints to STDERR dissapeared. But the html page was printed to the
apache log, basicly standard error. So it looks like if the socket is closed,
stderr dissapears, and stdout goes to the error log. So no pointers appeared in
the log, which wasn't very helpful.

Next attempt was to do some packet sniffing to see why the socket was closeing.
Turns out that the web server sends an orderly release indication (T_ORDEL_IND =
132), so the client being a good citizen reponds with a orderly release request
and there goes the socket.

While my description of the problem was more in-depth that I meant it to be, my
point is that now I'm left with the need to trace through system calls made by
apache, mod_perl and my program to try and find wh

Re: mod_perl advocacy project resurrection

[Jim Woodgate]

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...

-- 
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Robin Berjon]

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.

-- robin b.
You can tune a piano, but you can't tuna fish.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[David Hodgkinson]

Stas Bekman <[EMAIL PROTECTED]> writes:

> Yeah, but I don't seem to make other interested. I don't know why. Folks
> are too busy I guess.

It's blogger syndrome. You need to do it in parallel with the
development. The only reason my mod_perl/FastCGI comparison got
written was because those nice people at EMAP Online let me spend a
little time in the office (and a lot more on the train!) to tidy it
up.

I've got a handler code fragment using the TT that needs tidying up
and extending that I think would make a nice little case study. Where
should we take this kind of thing?



BTW, I tried subscribing to the mod_perl advocacy list:

<[EMAIL PROTECTED]>:
Sorry, no mailbox here by that name. (#5.1.1)

-- 
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star   http://www.deep-purple.com
  Apache, mod_perl, MySQL, Sybase hired gun for, well, hire
  -

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[David Hodgkinson]

barries <[EMAIL PROTECTED]> writes:

> If you could release a source distro of same with a big, red "make"
> button on it that would allow folks on FreeBSD, debian, wherever to take
> a stab at it too, that would be icing on the cake.

Me too ;-)

I mean, what would the damage of a full-on, everything binary be? Ten,
twenty megs?

OK, so we argue over whether to bundle MySQL or Postgres, but I see no
objection to an install that "just works". Especially if there's a
whole set of application recipies bundled.

-- 
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star   http://www.deep-purple.com
  Apache, mod_perl, MySQL, Sybase hired gun for, well, hire
  -

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[barries]

On Wed, Dec 06, 2000 at 12:08:59PM +, Matt Sergeant wrote:
> 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?

We're not (really) talking about appealing to "Perl people" here, I
think, but about appealing to people who know how to spell "Perl".  By
this I mean we are talking about attracting developers who haven't
climbed the learning curves for Perl and Apache and mod_perl and DBI and
so on and would like an easy way to play with these things.

If you could do a few stand-alone releases you're proposing without
having to maintain too many binary releases, you would probably woo more
people in to trying it.  There's a big something to be said for being
able to grab a "starter kit" that "just works" and play with it.

Do that for RH6 & 7 and NT and promote the kits as nice, shallow
jumping-in places and more folks will get in and paddle around a bit
with AxKit, I think.

If you could release a source distro of same with a big, red "make"
button on it that would allow folks on FreeBSD, debian, wherever to take
a stab at it too, that would be icing on the cake.

Some compromises for out-of-box ease would be necessary.  Make it run on
a high-numbered port so any user can run it, and make it easy to
reconfig to port 80 if they want to get serious.  Choose a database that
can be bundled and "just work".  Etc.

- Barrie

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Stas Bekman]

> > I've dropped my last job, in order to finally finish the mod_perl book,
> > have some rest and make a push to mod_perl.
> > 
> 
> Well best of luck & hope you have a good rest - I'll certainly buy the
> book!

:)

> > I see two main streams:
> > 1) Online zines.
> > 2) Conferences.
> > 
> > I think that we should start working on locating ezines wanting to publish
> > mod_perl related articles (preferrably for a fee, to give incentives for
> > others to write) and conferences where mod_perl can be relevant. The data
> > is to be collected and distributed to the people who wish to advocate
> > mod_perl, thru written articles and conference classes. I suppose that we
> > will also look for companies who want to order mod_perl classes and find
> > the teachers in the appropriate areas.
> 
> I think may people could write simple "How to ZXY" in mod_perl.  PHP has
> excellent resources for similar things i.e how to do this or that.  Very
> much like the Perl Cookbook.
> 
> I am not saying that mod_perl does not have these, and the guide has
> some excellent examples, but these are often not easy to find and will
> not attact people half as much as reading a single all-in one atricle.

Right, so anybody wants to get famous (well at least a little :), you
wrote some cool code snippet -- describe the gist, attach the source and
let others look over it. Sort of WebTechniques columns by Randal. 

> > May be we could organize some certification classes, to give more PR to
> > mod_perl.
> 
> Not wishing to sound negative - but certification more often causes
> problems - MCSE's a case in point.

well, may be. Obviously we don't need certifications when we cannot find
mod_perl programmers at all. I just thought about it as the
counter-intuitive solution -- create the certification program and make
people think that there are so many mod_perl programmers that we there was
a need for a certification -- which will bring to the interest, since
people believe that if someone is running certification program it must be
good. And then once started to learn Perl/mod_perl he is actually going to
realize that it's good indeed.

> Overall Stas I think more aticles in the general IT press be it ezines
> or in paper is the way to go to raise the profile.

Yeah, but I don't seem to make other interested. I don't know why. Folks
are too busy I guess.

> As an aside whats happening to perl month ? as this appears to be
> exactly the sort of thing we need.

I don't know. Baiju told me back in August that he resumes the
functionality but he has dissapeared since then. I'll try to reach him.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection (and a proposal!)

[Tim Sweetman]

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.

Cheers

--
Tim Sweetman
A L Digital
'Now you see this one-eyed midget shouting the word "now"...'
 --- Bob Dylan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Matt Sergeant]

On 6 Dec 2000, David Hodgkinson wrote:

> Matt Sergeant <[EMAIL PROTECTED]> 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?

-- 


/||** 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[David Hodgkinson]

Matt Sergeant <[EMAIL PROTECTED]> 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...

-- 
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star   http://www.deep-purple.com
  Apache, mod_perl, MySQL, Sybase hired gun for, well, hire
  -

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Greg Cope]

Stas Bekman wrote:
> 
> Well as you've probably figured out, based on the load of email from me,
> I've dropped my last job, in order to finally finish the mod_perl book,
> have some rest and make a push to mod_perl.
> 

Well best of luck & hope you have a good rest - I'll certainly buy the
book!

> In Paris we couldn't hire a single mod_perl programmer, because people
> don't even know what that. They know a lot about php and ASP. It's true
> that they don't even know what's Perl :(

I think this is a general situation - sounds similar to the uk.

> 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.

> mod_perl lucks the corporate money/PR to get pushed. But we can still work
> on the exposure, which will bring corporate money/PR thru the word of the
> mouth.

I think your on the right track, as many other popular open source
things have started this way. 

\> Luckily Matt has got sick of waiting for someone to work on the
advocacy
> of mod_perl and he has just taken over it. Having a good informational
> site is good, but it's not enough. We need to solve the problem of people
> to find this site and wanting to use mod_perl. Solution? Spreading the
> word.
> 
> I see two main streams:
> 1) Online zines.
> 2) Conferences.
> 
> I think that we should start working on locating ezines wanting to publish
> mod_perl related articles (preferrably for a fee, to give incentives for
> others to write) and conferences where mod_perl can be relevant. The data
> is to be collected and distributed to the people who wish to advocate
> mod_perl, thru written articles and conference classes. I suppose that we
> will also look for companies who want to order mod_perl classes and find
> the teachers in the appropriate areas.

I think may people could write simple "How to ZXY" in mod_perl.  PHP has
excellent resources for similar things i.e how to do this or that.  Very
much like the Perl Cookbook.

I am not saying that mod_perl does not have these, and the guide has
some excellent examples, but these are often not easy to find and will
not attact people half as much as reading a single all-in one atricle.

> May be we could organize some certification classes, to give more PR to
> mod_perl.

Not wishing to sound negative - but certification more often causes
problems - MCSE's a case in point.

Overall Stas I think more aticles in the general IT press be it ezines
or in paper is the way to go to raise the profile.

As an aside whats happening to perl month ? as this appears to be
exactly the sort of thing we need.

Greg

> I suppose that much more can be done. Comments are welcome.
> 
> _
> Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
> http://stason.org/   mod_perl Guide  http://perl.apache.org/guide
> mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
> http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

J2EE and distributed commits (was Re: mod_perl advocacy project resurrection)

[Tim Sweetman]

I'll bite, 'cuz I think I've run several times recently into this sort
of issue. I've not done anything with J2EE, so there's a risk that I've
misunderstood _that_. Now, from the top:

> 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.

Logged relational databases have evolved to ensure "atomic"[1]
transactions. This is to avoid embarrassing incidents like me giving you
a dollar[2], but a system crash midway means that we both end up with
the dollar. Or neither of us have it.

If the application catches a SIGKILL (say), the RDBMS "rolls back" to
the beginning of the transaction (I've still got my dollar).

If the RDBMS catches a SIGKILL, or a digger goes through the power
cable, the system is built so that it can restore itself to its previous
state.

A variety of safeguards are used so that transactions are very hard to
lose. Often, a TX is not regarded as committed until it's been written
to disk. Logs are periodically written to tape, in case the disk gets
scrunched (or the RDBMS software blows up).

In short:
The losing of transactions is Greatly Discouraged, but can happen.
_Inconsistant_ processing of transactions should be *impossible*.

Distributed transactions, where you have two systems (say my bank and
yours are on separate machines), simply cannot be made as reliable.
There is *always* the problem that, in a single system, there is _A_ log
that records whether the transaction has happened. With two systems, the
record must be made in two places, and there is always an instant in
time - however small - when one system can crash leaving the other
believing that the transaction has been successful. (IIRC, textbooks
sometimes call this the "red & white army problem").

This sort of problem is *not* confined to finance. You may, for
instance, be maintaining lists of usernames & passwords in multiple
locations.

There are a variety of approaches to this sort of problem:
1. Use a single database.

2. Make one database the "slave" of the other.
   If the DB is too big to copy, you can use a "hybrid" approach where
changes are propagated, but
   the DBs are periodically sync'd. Or use something like rsync, which
makes two database/file trees
   /whatever identical without brute-force copying the whole thing.

3. Be careful with foreign keys on other people's servers
   ... since there may be no way to find out when those become invalid,
or point to something else.
   (Hence, the dreaded "link rot" suffered by search engines).

As evidenced by the WWW's popularity explosion, loosely coupled
distributed systems are in many ways very powerful. Trying to force
"everything" via a single system, whilst tackling problems of
consistency & transaction processing, can be crippling. Different
approaches suit different apps, but pretending the problem isn't there
isn't generally a good approach.

Hope that helps.

--
Tim Sweetman
A L Digital
'Now you see this one-eyed midget shouting the word "now"...'
 --- Bob Dylan

[1] That's unsplittable, like atoms are, except the radioactive ones, or
if you're cheating and
have a particle accelerator.

[2] I'm guessing there are lots of Americans here, and going with the
majority. When Euros are
in wider use, I'll use that as my metasyntactic currency unit.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection (and a proposal!)

[Matthew Byng-Maddick]

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.  

http://codix.net/.

> 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.

Re: mod_perl advocacy project resurrection

[Matthew Byng-Maddick]

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: <[EMAIL PROTECTED]>  +44 20  8981 8633  (Home)
http://colondot.net/   Work: <[EMAIL PROTECTED]> +44 7956 613942  (Mobile)
Genius may have  its limitations,  but stupidity  is not thus handicapped.
 -- Elbert Hubbard


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Perrin Harkins]

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.

- Perrin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Matt Sergeant]

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)?

-- 


/||** 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[Matt Sergeant]

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.

-- 


/||** 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Matt Sergeant]

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;

-- 


/||** 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Gunther Birznieks]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Gunther Birznieks]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Dave Rolsky]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Jim Woodgate]

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.

-- 
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Chris Winters]

* Ben Cottrell ([EMAIL PROTECTED]) [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 ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[Michael Robinton]

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.
> > 

> 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.
> 

> > 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[Stuart Frew]

>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:[EMAIL PROTECTED]]
> Sent: Tuesday, December 05, 2000 10:25 AM
> To: [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection (messaging system)

[Dave Rolsky]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[brian moseley]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Jeffrey W. Baker]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Ajit Deshpande]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[Jeffrey W. Baker]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[brian moseley]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[brian moseley]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Perrin Harkins]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[brian moseley]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[Perrin Harkins]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: XML::ValidWriter -> \$scaler [Was: mod_perl advocacy project resurrection]

[barries]

On Tue, Dec 05, 2000 at 07:03:58PM -0500, Drew Taylor wrote:
> barries wrote:
> 
> I stand corrected. :-) I'll play around with XML::ValidWriter and see
> what happens.

It also requires a more recent XML::Parser to slurp up DTDs, but DTDs
can be saved as Perl modules and you don't need to load XML::Parser to
use them.

- Barrie

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[brian moseley]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: XML::ValidWriter -> \$scaler [Was: mod_perl advocacy project resurrection]

[Drew Taylor]

barries wrote:
> 
> On Tue, Dec 05, 2000 at 05:31:49PM -0500, Drew Taylor wrote:
> >
> 
> I've used XML::Checker::Parser with no big issues.

Good to hear. Unfortunately, we are using an older version of
XML::Parser (2.22), while XML::Checker requires 2.23 (according to make
test). I'm not going to even try to get this upgraded on the production
site knowing how finicky XML::Parser can be. But I'll definately keep it
in mind should we upgrade in the future. I see our API becoming much
more important in the near future, and this might help get things
upgraded sooner.

> > My biggest problem with XML::Writer (and hence XML::ValidWriter) is that
> > I can't write to a string, unless there is some hackish workaround.
> 
> XML::ValidWriter writes to a string if you pass in a \$scalar as the
> destination:
> 
>new
>   $writer = XML::ValidWriter->new( DTD => $dtd, OUTPUT => \*FH ) ;
> 
>Creates an XML::ValidWriter.
> 
>The value passed for OUTPUT may be:
> 
>a SCALAR ref
>if you want to direct output to append to a
>scalar.  This scalar is truncated whenever the
>XML::ValidWriter object is reset() or DESTROY()ed

I stand corrected. :-) I'll play around with XML::ValidWriter and see
what happens. Of course, I also happen to like the way we generate XML
now. It's just a big array of arrays of arrays... reference that is
walked to make the XML. Pretty neat, and the implementation is actually
very simple.

-- 
Drew Taylor
Software Engineer
OpenAir.com - Making Business a Breeze!
Open a free account today at www.openair.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Gunther Birznieks]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[OT] Starting a Company on OS [Was: mod_perl longevity] [Was: mod_perl advocacy project resurrection]

[Gunther Birznieks]

I thought I would change the topic yet again. :)

At 02:58 PM 12/5/00 -0500, Ajit Deshpande wrote:
>On Tue, Dec 05, 2000 at 11:34:49AM -0800, brian moseley wrote:
> > 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.

That's a very techie thing to think about. I'll stay out of this part of 
the conversation as I said my piece on it in several other threads over the 
past 2 years. :)

I would be very careful about setting up a business entirely around 
mod_perl for several reasons (couched in an anecdote about my experience 
starting a company).

We started a company around our open source products 8 months ago and left 
the cushy full-time job sector. While I don't regret starting the open 
source company I have say several things that we discovered (really common 
sense but)...

1) Even if you hire a good business team to back up you as techs, at least 
one of you will not be coding or engineering anymore. You will be business 
development/sales/marketing/providing support in writing and revising the 
business plan, making the next strategic alliance, closing the next big 
deal (big deals take a lot of time to close both length of time and 
building the relationship).

The mod_perl community will definitely lose one of you guys for sure.

2) Service/Consulting contracts extremely time consuming to administrate if 
you want to manage it "right".

3) It's a bad idea to make a company dependent on the fact that you have 3 
really hot-shit developers because

(A) one of you will be taken away for business things, almost guaranteed
(B) Your clients will want YOU to work on it not someone you hired and 
trained -- because until they've been working on mod_perl for several 
months, it is unlikely they would be doing work. In the meantime you pay 
someone a salary to learn enough to be good enough (so prepare for a 1-3 
month buffer of paying salary).
(C) Service based company's make money off of headcount not off of a few 
good people.

4) Unless you are injecting a lot of cash into your company or know someone 
who will, you will not reach a critical mass of directly billable headcount 
necessary to generate revenue which will take care of the "overhead" you 
need to hire to grow a company beyond a couple of people (CEO, Business 
Development, COO, Marketing, WebMaster/Graphics guy (invariables 
infrastructure contracts ask if you can also take on a tiny bit of apps 
work and then it will also be an issue of doing graphics for their site) 
and CF0) maybe in that order ... but that's another room for debate that's 
not for this list.

It's really hard to do this on your own money. We started our company with 
5 people. 2 techs, 3 business. We've grown in 8 months to 15 people. But 
the process has not been easy. The first 6 months definitely took me away 
from posting here (some would say that's a good thing) and it's completely 
taken away the other tech who I started with as he is still mired into 
doing business stuff.

If he has spare time it isn't to do open source as much anymore as to code 
to generate revenue so we can hire more people.

Of course, getting funding is cool (the VC route), but we haven't done that 
route. The VCs we've gone to all want over 51% of your company to give you 
money (especially these days)... Losing control sucks when you are doing 
something you are passionate about (open source).

And they also want to see that your team has run a business from scratch 
before. This was a minor problem for us when we started looking at funding 
opportunities, although not anymore as the same VCs are now impressed we 
survived and prospered without funding at a time when dotcom's have been 
dropping like flies.

Dotcom Funerals are really hard to watch and demoralizing also. I would not 
want to see a mod_perl-based dotcom funeral because some VC was controlling 
the company and that VC doesn't understand open source.

Of course, this may be sour grapes, but at this stage, although funding 
would be fantastic, I shudder to think that if we had funding from the 
wrong VC or investor then we would be screwed.

Anyway, the summary of this story is that running a business if really 
hard. I thought going into it that quiting my full time job to work in an 
open source company would mean more time to do open source and advocacy.

Boy was I wrong. The process of starting a company took me out for 6 
months, and only now am I getting back into it. I love doing the company 
thing and I've learned a lot about real business (especially making the 
hard decisions that you have to when you dont have gobs of money), but it's 
still completely not what I expected 

RE: mod_perl advocacy project resurrection

[Michael Nachbaur]

> > 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[Paul]

--- brian moseley <[EMAIL PROTECTED]> 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!

===

Hey, how about a link/page like the contract sites use?
Someone posts an "I need [so&so]", and someone else writes one and
posts it. Maybe the site would allow a fee to download (a dollar? an
amount set by the author?), splitting all the proceeds with the
author and letting anyone who downloads it do a review?  We could even
start the site off with cross-links to CPAN's free stuff, and users
could spend their dollar just to post
comments/suggestions/reviews/requests/complaints about the modules


__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection (and a proposal!)

[Dave Rolsky]

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.


-dave

/*==
www.urth.org
We await the New Sun
==*/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[Perrin Harkins]

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.

- Perrin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Gunther Birznieks]

This is exactly why someone experienced in training (ie Randal/StoneHenge) 
would hopefully be the ones to take the torch on this. If there's anyone I 
would trust a certification from, it would be them.

At 02:07 PM 12/5/00 -0800, Ask Bjoern Hansen wrote:
>On Tue, 5 Dec 2000, Stas Bekman wrote:
>
>[...]
> > May be we could organize some certification classes, to give more PR to
> > mod_perl.
>
>Certification's are really hard and really expensive to do and
>pretty much crap even done well. We don't want anything to do with
>it.
>
>(IMO)
>
>
>  - ask
>
>--
>ask bjoern hansen - 
>more than 70M impressions per day, 
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]

__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Tom Lancaster]

> Certification's are really hard and really expensive to do and
> pretty much crap even done well. We don't want anything to do with
> it.
>  
> (IMO)
> 
> 
>  - ask

If you want to check if someone's certifiable, just search for their name in the 
archives of this list.
Anyone you would want to hire has probably contributed something here.
No pun intended, BTW.


-- 
Tom Lancaster   Red Hat, Inc.
Web Engineer(415) 777-9810 x 228

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

XML::ValidWriter -> \$scaler [Was: mod_perl advocacy project resurrection]

[barries]

On Tue, Dec 05, 2000 at 05:31:49PM -0500, Drew Taylor wrote:
> 

I've used XML::Checker::Parser with no big issues.

> My biggest problem with XML::Writer (and hence XML::ValidWriter) is that
> I can't write to a string, unless there is some hackish workaround.

XML::ValidWriter writes to a string if you pass in a \$scalar as the
destination:

   new
  $writer = XML::ValidWriter->new( DTD => $dtd, OUTPUT => \*FH ) ;

   Creates an XML::ValidWriter.

   The value passed for OUTPUT may be:

   a SCALAR ref
   if you want to direct output to append to a
   scalar.  This scalar is truncated whenever the
   XML::ValidWriter object is reset() or DESTROY()ed

   a file handle glob ref or a reference to an IO object
   XML::ValidWriter does not load IO.  This is the
   only mode compatible with XML::Writer.

   a file name
   A simple scalar is taken to be a filename to be
   created or truncated and emitted to.  This file
   will be closed when the XML::ValidWriter object is
   reset or deatroyed.

- Barrie

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Gunther Birznieks]

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.

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.

The problem is mod_perl is not easy. Make a CGI/Perl solution for speeding 
up CGIs EASY and you will find people migrating back from PHP to Perl. 
Attending the PHP talks at ApacheCon/Europe, if there was one thing I 
found, PHP as a language is still REALLY new. PHP4 is the first really 
professional version of PHP, PHP3 is filled with a lot of skeletons. And I 
heard people still arguing about PHP4's language merits.

Rasmus posted on BUGTRAQ the other day about some security problems with 
PHP scripts coming up (there have been several in the last week)... He 
posted that anyone running the scripts should upgrade to PHP4. Yet people 
are still finding it hard to upgrade to PHP4. So those people will have to 
go through hoops to shutdown security problems in their public domain PHP 
apps?

Larry Wall was a genius in creating a great language with ease of 
expression. But we didn't carry the torch to make it fast and easy.

By the way, I *LOVE* SpeedyCGI and mod_speedy. I forget who mentioned it to 
me at ApacheCon/Europe, but THANK YOU SO MUCH.

For those of you that have not  seen the project, please try it out. It 
makes speeding up CGI/Perl almost trivial. And it's definitely an ISPable 
solution because it plugs into Apache's CGI mechanism (non of the annoyance 
of giving plain users control over handlers).

And oh yeah, SpeedyCGI is web server independent. It works just as well on 
Netscape (which is where I had to use it on a client site).

The model is similar to FastCGI, but SpeedyCGI is trivial to setup unlike 
FastCGI which requires modification to the app.

At 09:22 AM 12/5/00 -0800, Paul wrote:

>--- Stas Bekman <[EMAIL PROTECTED]> wrote:
>.
> > I see two main streams:
> > 1) Online zines.
> > 2) Conferences.
>
>Apache.org has a whole subsection devoted to mod_perl
>Any idea what it would take to get a link there from webs like tpj and
>Perl.com?  I was thinking that perl.com has a nice series of articles
>going for newcomers to the language, and Mark Jason-Dominus' series of
>red-flag articles has certainly been worth a read; wouldn't a less
>generic article series for less-new users interested in perl topics
>like Apache be worth space and a link?  I've seen links to specific
>high-profile uses like the Human Genome Project as Perl advocacy.
>Wouldn't mod_perl be worth an ongoing link page in that right, perhaps
>with discussions of sites handling thorny problems?  Or am I behind the
>times on that one?
>
>I'd even volunteer to write a few articles, though I hardly consider
>myself qualified to teach anything more than the basic concepts.  I'm
>still on the steep side of the learning curve for designing effective
>and efficient subsites with handlers and some Embperl, but our shop has
>some odd needs that mod_perl seems built-for, and I do love to talk
>
>comments?
>
>__
>Do You Yahoo!?
>Yahoo! Shopping - Thousands of Stores. Millions of Products.
>http://shopping.yahoo.com/
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]

__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[brian moseley]

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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Matthew Kennedy]

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?

> - Perrin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Perrin Harkins]

On Tue, 5 Dec 2000, brian moseley wrote:
> i know there are several people on the list who swear by
> "all handlers, all the time". i've never heard anybody give
> a reason for that preference that actually made sense to me.

That usually comes up in the context of handlers vs. Apache::Registry.  
I've never heard anyone argue that you should always write handlers from
scratch instead of developing (or downloading) a framework along the lines
of your AO project.

- Perrin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[barries]

On Tue, Dec 05, 2000 at 04:10:01PM -0500, Drew Taylor wrote:
> 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?

Will XML::Checker::Parser do?

> 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.

And, if you want to validate while writing, XML::ValidWriter
might help.

- Barrie

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Perrin Harkins]

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.

- Perrin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Drew Taylor]

barries wrote:
> 
> On Tue, Dec 05, 2000 at 04:10:01PM -0500, Drew Taylor wrote:
> > 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?
> 
> Will XML::Checker::Parser do?

Hmmm, looks interesting. I'll check into it. Any experience (good or
bad) with it? I see that it relies on XML::Parser. How well does
XML::Parser handle the newly available external DTD feature?

> > 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.
> 
> And, if you want to validate while writing, XML::ValidWriter
> might help.

My biggest problem with XML::Writer (and hence XML::ValidWriter) is that
I can't write to a string, unless there is some hackish workaround. I
remember someone talking about an IO::String sort of module, but it
sounds like using a sledhammer to drive a nail. ;-) I did actually check
out XML::Writer, and even went to far as to replace the IO handle stuff
with a plain old string. But then decided to use something else. While I
love the idea of validating as I write XML, it doesn't help on the other
end. :-(

-- 
Drew Taylor
Software Engineer
Phone: 617.351.0245
Fax 617.350.3496
OpenAir.com - Making Business a Breeze!
Open a free account today at www.openair.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Ask Bjoern Hansen]

On Tue, 5 Dec 2000, Stas Bekman wrote:

[...]
> May be we could organize some certification classes, to give more PR to
> mod_perl.

Certification's are really hard and really expensive to do and
pretty much crap even done well. We don't want anything to do with
it.
 
(IMO)


 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[brian moseley]

On Tue, 5 Dec 2000, kevin montuori wrote:

>   i'm not sure about "all handlers, all the time" but a good deal
>   of what i'm using mod_perl for is session management, credential
>   maintenance, custom logging, on-the-fly compression, and other
>   "housekeeping" tasks.  i think only 10% of my handlers are
>   content handlers, the other 90% do things neither CGI nor an
>   application server are going to do.

in fact, these are exactly the problems ao is meant to
solve. the idea is that for now, we provide a presentation
tier environment with hooks to allow you to integrate middle
tier functionality, but eventually it would be nice to also
create a real j2ee like environment with separate front and
middle tiers, where presentation and business logic can be
varied and scaled separately.

>   if for no other reason than time to market, it's nice to have
>   access to the server API in Perl rather than C.  it took only
>   hours to whomp up handlers to help integrate netegrity's
>   siteminder product into our existing site; it would have been
>   weeks if it had to be written in C.

yup, it's always going to be nice to have direct access to
low-level components. as someone pointed out earlier, some
people will always require it. i'm shooting to make 80% of
people happy rather than 20%.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[brian moseley]

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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[brian moseley]

On Tue, 5 Dec 2000, Ajit Deshpande wrote:

> IMHO, it shouldnt be that difficult if you make some
> good assumptions.  For example, how difficult will it be
> to maintain the following package:
> 
>1. Assume Perl 5.5.3 OR 5.6.0
>2. Assume latest Apache and static mod_perl
>3. Assume latest Apache::DBI, Apache::Session,
>4. Assume latest HTML::Mason (I cant speak for the others, yet)
>5. Assume latest MySQL
> 
> Now, with the above, I think we can maintain a basic
> demo, templating system with session management using
> Apache::DBI fairly easily.

fwiw, those are exactly the components the current version
of ao supports out of the box.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Jens-Uwe Mager]

On Tue, Dec 05, 2000 at 04:14:13PM -0500, darren chamberlain wrote:

> Perhaps the solution is a complete, precompiled package, something that
> has Perl, Apache, mod_perl, and all the required modules prebuilt, in
> various formats: RPM, deb, tgz, Solaris pkg, and just regular tarballs.

Exactly, and one has to make sure that perl is in the prebuilt package
as well, probably even using a seperate path from the normally used perl
locations, for example /usr/local/apache/perl for the perl installation.
It is crucially important to have all of apache, apache modules,
mod_perl and perl moduless built using a exactly the same compiler and a
coherent set of compiler flags.

-- 
Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:  +49 5131 709320
FAX:+49 5131 709325
Internet:   [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Matt Sergeant]

On Tue, 5 Dec 2000, (Matthew Kennedy) 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?
>
> 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).

XML support I think we have mostly covered now (or maybe you disagree?).

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.

-- 


/||** 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[Michael Nachbaur]

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:[EMAIL PROTECTED]]
Sent: Tuesday, December 05, 2000 10:25 AM
To: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Ben Cottrell]

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.


Kinda hard to laugh hangin' there in one o' them "virtual machines", Rob...


~Ben
 (this message comes guaranteed to offend absolutely everybody in
 some fashion or other)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection (and a proposal!)

[kyle dawkins]

Everybody

This whole call for mod_perl advocacy is definitely a good thing.  But we're 
not going to get anywhere unless we understand the problem in detail.  We can 
run around all we like talking numbers and touting the virtues of mod_perl 
but it's not going to actually do anything unless we address some fundamental 
issues.  I don't claim to know the answers to these problems, but I do think 
I can at least start the ball rolling the right direction to get others 
thinking about what next.

If we're on this list, there's a good chance we think we have a good 
understanding of mod_perl.   Or at least a good understanding of the parts of 
the massive mod_perl beastie that we use.  I use it all day every day but 
don't claim to know anything about Authentication, for example.   I'm sure I 
could read the chapters in the eagle book and figure it out, but I don't know 
anything about it now.

So, making that assumption, I want to bring up a few issues that I see as 
crucial.

1. We are worried that mod_perl is not being adopted as a server technology 
in enough places.   This is actually TWO problems, not one, and to treat is 
as one is missing the point.   There are TWO different kinds of developer out 
there.  The first is someone who is probably not a programmer by trade, but 
has picked up CGI and/or PHP/ASP programming from a "21 days" book or by 
reading through examples.  There are a number of reasons why *these* people 
have not jumped all over mod_perl... I'm sure we all know what those reasons 
are.The second group of people are *engineers* (or *developers*).  These 
people need something different out of mod_perl.  They need good docs, 
examples, stability, community support, and FOUNDATION CLASSES (more on this 
later)

2. Perl
Let's face it, we love Perl, but a lot of people don't, because *they don't 
understand it*.  Remember, a lot of people might have looked at Perl 4 when 
it was a disastrous hodgepodge and not looked at it since.  Perl 5 is an 
infinitely better language than 4, but most people don't know that.  In order 
for Perl to be acceptable in larger institutions with an already-established 
software engineering group, changes to Perl itself need to be made.  See more 
below.

3. Installation/setup
Ok, so if you have Linux, it's a piece of cake... download all the sources, 
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 
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.

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.  

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.

which brings me to...

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 
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... 
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.

--> 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!):

* 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...
* We "homogenise" some foundation classes.  This means we create a *suite* of 
classes that have consistent API, are designed together as a framework, a

Re: mod_perl advocacy project resurrection

[kevin montuori]

>>> brian moseley writes:

  bm> i know there are several people on the list who swear by "all
  bm> handlers, all the time". i've never heard anybody give a reason
  bm> for that preference that actually made sense to me.

  i'm not sure about "all handlers, all the time" but a good deal
  of what i'm using mod_perl for is session management, credential
  maintenance, custom logging, on-the-fly compression, and other
  "housekeeping" tasks.  i think only 10% of my handlers are
  content handlers, the other 90% do things neither CGI nor an
  application server are going to do.

  if for no other reason than time to market, it's nice to have
  access to the server API in Perl rather than C.  it took only
  hours to whomp up handlers to help integrate netegrity's
  siteminder product into our existing site; it would have been
  weeks if it had to be written in C.

  cheers,
  k.

-- 
kevin montuori

support independent booksellers -- http://www.booksense.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Matt Sergeant]

On Tue, 5 Dec 2000, Ajit Deshpande wrote:

> On Tue, Dec 05, 2000 at 08:26:35PM +, Matt Sergeant wrote:
> > > application should install itself -- .conf files, .htaccess files,
> > > dbm's, directory structures, perl code, html and templates, correct
> > > version of Perl, CPAN packages for any stuff needed, Apache, mod_perl,
> > > mod_ssl, mod_whatever, mysql, database schemas, database contents,
> > > DBI, Session, front-end proxy -- everything.  Each application should
> > > gronk whatever's already there, or rename it out of the way.
> > > Warnings in big letters.  Tough doots.
> >
> > Do you have any idea how hard this is? Seriously. Because I do. Dave
> > Rolsky does. And doing this for free is going to be nigh on impossible.
>
> IMHO, it shouldnt be that difficult if you make some good assumptions.
> For example, how difficult will it be to maintain the following package:
>
>1. Assume Perl 5.5.3 OR 5.6.0
>2. Assume latest Apache and static mod_perl
>3. Assume latest Apache::DBI, Apache::Session,
>4. Assume latest HTML::Mason (I cant speak for the others, yet)
>5. Assume latest MySQL
>
> Now, with the above, I think we can maintain a basic demo, templating
> system with session management using Apache::DBI fairly easily.

I can only suggest you try it as I speak from experience.

-- 


/||** 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Ajit Deshpande]

On Tue, Dec 05, 2000 at 08:26:35PM +, Matt Sergeant wrote:
> > application should install itself -- .conf files, .htaccess files,
> > dbm's, directory structures, perl code, html and templates, correct
> > version of Perl, CPAN packages for any stuff needed, Apache, mod_perl,
> > mod_ssl, mod_whatever, mysql, database schemas, database contents,
> > DBI, Session, front-end proxy -- everything.  Each application should
> > gronk whatever's already there, or rename it out of the way.
> > Warnings in big letters.  Tough doots.
> 
> Do you have any idea how hard this is? Seriously. Because I do. Dave
> Rolsky does. And doing this for free is going to be nigh on impossible.

IMHO, it shouldnt be that difficult if you make some good assumptions. 
For example, how difficult will it be to maintain the following package:

   1. Assume Perl 5.5.3 OR 5.6.0
   2. Assume latest Apache and static mod_perl
   3. Assume latest Apache::DBI, Apache::Session,
   4. Assume latest HTML::Mason (I cant speak for the others, yet)
   5. Assume latest MySQL

Now, with the above, I think we can maintain a basic demo, templating
system with session management using Apache::DBI fairly easily.

Ajit

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[darren chamberlain]

kevin montuori ([EMAIL PROTECTED]) said something to this effect:
> >>> David Hodgkinson writes:
>   prebuilt solves the problem nicely for people running linux;
>   however, that's not everybody.  i'm sure there are sun shops out
>   there without the sysadmin expertise to download and compile
>   mod_perl properly.  i'd rather see the configure/compile process
>   simplified than try to provide binaries for a dozen platforms --
>   that would allow the folks who'd be tied to compiling each new
>   release to do more interesting and profitable things.

Perhaps the solution is a complete, precompiled package, something that
has Perl, Apache, mod_perl, and all the required modules prebuilt, in
various formats: RPM, deb, tgz, Solaris pkg, and just regular tarballs.

ActiveState has a generic, relocatable tarball of ActivePerl that can
be moved around. It's very nice -- simple to install, answer a few
questions, and the whole things gets put where you want it.

With a handful of maintainers and a lot of diskspace, a number of 
configurations can be created.

This is something I'd be willing to devote some time to. If anyone finds
a home for something like this, consider me a volunteer.

(darren)

-- 
It has long been an axiom of mine that the little things are infinitely
the most important.
-- Arthur Conan Coyle

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[Matt Sergeant]

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.

-- 


/||** 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Drew Taylor]

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"?

-- 
Drew Taylor
Software Engineer
OpenAir.com - Making Business a Breeze!
Open a free account today at www.openair.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [OT] mod_perl longevity [Was: mod_perl advocacy project resurrection]

[Ajit Deshpande]

On Tue, Dec 05, 2000 at 12:28:08PM -0800, brian moseley wrote:
> 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.

well, there is always going to be a niche market for cleverly 
hand-crafted web-infrastructure solutions. personally, thats
the space i am interested in.

also, imo, the notion of building enterprise-ready app-infrastructures 
overnight by deploying infrastrucutre components from some big-name 
vendor may not always be feasible.

the size of the pond where people can get by with off-the-shelf
components is defintely bigger, i would agree. but you are never 
gonna find the Amazons, the Yahoos, the Hotmails and the Valueclicks 
get by with those. 

so, if you, doug & jon start a company, dont you think every new 
mod_perl based nich web company is gonna call on your combined 
expertise! *dammit* start the company already! (and then hire me 
to do the grunt mod_perl work :)

ajit

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[martin langhoff]

Eric Strovink wrote:
> 
> A number of people have been beating around this bush, so why not just mow it down?
> 
> A huge win for advocacy would be a small set of complete example applications
> targetted at, say, the last two RedHat distros.  

I see a suitable target there ... maybe a SRPM bundling:

Apache + mod_perl + libapreq + DBI + DBD::Mysql + HTML::Embperl +
Apache::ASP + Template Toolkit ... 

I guess it's important that we build a SRPM so the build sequence uses
the local perl intallation



martín

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Matthew Kennedy]

"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.



> 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).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Gerald Richter]

>
> i don't have figures, but from experience i know - once i've
> compiled httpd, i have almost no real configuration work to
> do with php. on the other hand, if i want to set up mason, i
> have to write 10-20 lines of perl code and access them with
> PerlModule or PerlRequire. if i want multiple mason sites i
> have to dig back into that perl script. certainly not
> difficult, but kinda irritating, and takes more effort to
> maintain, especially across multiple machines.
>

That's what I always tried to avoid within the configuration of Embperl. I
have tried to keep it as simple as possible for the first start. If you have
mod_perl up and running, you just tell Apache to handle for example .epl
files by HTML::Embperl and your are done. (exactly 6 lines to copy and paste
form the Embperl docs into yout httpd.conf ), but as I understand Jonathan
he (and Mason) has a slightly other intention in this area.

Gerald

-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:   Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151
WWW:http://www.ecos.de  Fax:  +49 6133 925152
-




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[brian moseley]

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.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]