You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Dave Rolsky <au...@urth.org> on 2000/12/06 20:11:25 UTC
Smart installing (Re: mod_perl advocacy project resurrection)
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
==================*/
Re: debuggers
Posted by Jeremy Howard <jh...@fastmail.fm>.
martin langhoff wrote:
> I wonder how do those hardcore guys that develop using handlers debug.
> Mhhh. They must write 'perlfect' code, I guess, and/or understand those
> cryptic debuggers ...
>
Actually, debugging handlers is pretty easy. Just run httpd with the -X flag
to make it single process, and use Apache::DB to get mod_perl to run under
the debugger. Get Apache::DB from CPAN
perl -MCPAN -e 'install Apache::DB'
and read its docs
perldoc Apache::DB
When Apache hits your Perl code, you are dropped into the standard Perl
debugger. Although typing '?' at the debug prompt shows a bewildering array
of options, you can do a lot by knowing:
n - Step over
s - Step into
x <expr> - Print the value of <expr>
w - Show a few lines either side of the current one
b <sub> - break at <sub>
c - continue (stop debugging)
c <line#> - continue, and break at <line#>
HTH,
Jeremy
Re: debuggers
Posted by Stas Bekman <st...@stason.org>.
On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
> >>>>> "Stas" == Stas Bekman <st...@stason.org> writes:
>
> >> Plus, I *always* use '-w' and '-T' and get them cleanly working
> >> during development phases, although I shut them off for actual
> >> deployment.
>
> Stas> 1. You cannot use -T under mod_perl, you should use
> Stas> PerlTaintCheck
> Stas> instead: http://perl.apache.org/guide/porting.html#Taint_Mode
>
> This is what I was referring to actually. However, there are many
> modules, such as Date::Manip, for example, that just will not load with
> taint checking turned on. In an intranet, it's not as big a deal as it
> certainly is in the 'real world'.
You should contact the author of the module and ask him to fix it. It's
possible that he doesn't aware of the taint issues. Usually for modules
that execute shell/fork but don't pass any tainted args, the fix is as
trivial as adding:
$ENV{'PATH'} = '/bin:/usr/bin';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
(taken from perlsec manpage)
Hmm, may be we should find a way for modules to be taint checked before
these are allowed to CPAN? What do you think? sort of:
eval {`perl -cwT $_` for (<*.pm>) };
> But what can I do, short of rewritting the parts of the module that
> don't function in with checking on
>
> Stas> 2. 'PerlTaintCheck On' is a must in production!!! not
> Stas> development:
> Stas> * http://www.gunther.web66.com/FAQS/taintmode.html
> Stas> * perldoc perlsec
>
> Thanks for the input.
You are very welcome :)
> Peace.
Sex, drugs and rock-n-roll!
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: debuggers
Posted by "Bruce W. Hoylman" <bh...@qwest.com>.
>>>>> "Stas" == Stas Bekman <st...@stason.org> writes:
>> Plus, I *always* use '-w' and '-T' and get them cleanly working
>> during development phases, although I shut them off for actual
>> deployment.
Stas> 1. You cannot use -T under mod_perl, you should use
Stas> PerlTaintCheck
Stas> instead: http://perl.apache.org/guide/porting.html#Taint_Mode
This is what I was referring to actually. However, there are many
modules, such as Date::Manip, for example, that just will not load with
taint checking turned on. In an intranet, it's not as big a deal as it
certainly is in the 'real world'.
But what can I do, short of rewritting the parts of the module that
don't function in with checking on
Stas> 2. 'PerlTaintCheck On' is a must in production!!! not
Stas> development:
Stas> * http://www.gunther.web66.com/FAQS/taintmode.html
Stas> * perldoc perlsec
Thanks for the input.
Peace.
Re: debuggers
Posted by Stas Bekman <st...@stason.org>.
> >>>>> "SB" == Stas Bekman <st...@stason.org> writes:
>
> SB> 2. 'PerlTaintCheck On' is a must in production!!! not development:
>
> Huh?!?!?!? It is a must always. You can't develop without it and
> then expect it to work with taint checking on at a later time.
Of course, sorry for being unclear. What I meant is that if your code runs
cleanly under PerlTaintCheck On on development server, you should still
keep in 'On' in production.
If you aware of all taint issues, you may skip PerlTaintCheck on dev, but
why doing so :)
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: debuggers
Posted by Vivek Khera <kh...@kciLink.com>.
>>>>> "SB" == Stas Bekman <st...@stason.org> writes:
SB> 2. 'PerlTaintCheck On' is a must in production!!! not development:
Huh?!?!?!? It is a must always. You can't develop without it and
then expect it to work with taint checking on at a later time.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: debuggers
Posted by Dave Rolsky <au...@urth.org>.
On Fri, 8 Dec 2000, Matt Sergeant wrote:
> fatalsToBrowser installs a $SIG{__DIE__} handler, and so prevents you from
> properly using eval{} blocks, or nice modules like Error.pm or
> Class::Exception (or whichever way around Dave has it this week :-)
That's Exception::Class. phhhbbtt!
-dave
/*==================
www.urth.org
We await the New Sun
==================*/
Re: debuggers
Posted by Matt Sergeant <ma...@sergeant.org>.
On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
> >>>>> "Matt" == Matt Sergeant <ma...@sergeant.org> writes:
>
> Matt> On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
> >>
> >> use IO::File;
> >> use CGI::Carp qw(carpout fatalsToBrowser carp);
> Matt> Bye bye exception handling.
>
> You mean eval{} block exception handling, or something else? What are
> the technical specifics around this assertion?
fatalsToBrowser installs a $SIG{__DIE__} handler, and so prevents you from
properly using eval{} blocks, or nice modules like Error.pm or
Class::Exception (or whichever way around Dave has it this week :-)
See my rant, erm, section in the guide on exception handling.
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: debuggers
Posted by Stas Bekman <st...@stason.org>.
On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
> >>>>> "Matt" == Matt Sergeant <ma...@sergeant.org> writes:
>
> Matt> On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
> >>
> >> use IO::File;
> >> use CGI::Carp qw(carpout fatalsToBrowser carp);
> Matt> Bye bye exception handling.
>
> You mean eval{} block exception handling, or something else? What are
> the technical specifics around this assertion?
>
> Thanks! Maybe I'll learn something here, which is why I posted it in
> the first place.
http://perl.apache.org/guide/perl.html#Exception_Handling_for_mod_perl
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: debuggers
Posted by "Bruce W. Hoylman" <bh...@qwest.com>.
>>>>> "Matt" == Matt Sergeant <ma...@sergeant.org> writes:
Matt> On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
>>
>> use IO::File;
>> use CGI::Carp qw(carpout fatalsToBrowser carp);
Matt> Bye bye exception handling.
You mean eval{} block exception handling, or something else? What are
the technical specifics around this assertion?
Thanks! Maybe I'll learn something here, which is why I posted it in
the first place.
Peace.
Re: debuggers
Posted by Stas Bekman <st...@stason.org>.
> Plus, I *always* use '-w' and '-T' and get them cleanly working during
> development phases, although I shut them off for actual deployment.
1. You cannot use -T under mod_perl, you should use PerlTaintCheck
instead: http://perl.apache.org/guide/porting.html#Taint_Mode
2. 'PerlTaintCheck On' is a must in production!!! not development:
* http://www.gunther.web66.com/FAQS/taintmode.html
* perldoc perlsec
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: debuggers
Posted by Matt Sergeant <ma...@sergeant.org>.
On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
> >>>>> "Dave" == Dave Rolsky <au...@urth.org> writes:
>
> Dave> On Thu, 7 Dec 2000, martin langhoff wrote:
> >> I wonder how do those hardcore guys that develop using handlers
> >> debug. Mhhh. They must write 'perlfect' code, I guess, and/or
> >> understand those cryptic debuggers ...
>
> Dave> I just do a lot of debugging via warn statements and looking
> Dave> at the error logs.
>
> My BEGIN block looks like this. I realize IO is rather bulky, but I
> like it and the environment I'm in isn't *that* busy where it makes a
> significant impact.
>
> BEGIN {
>
> # Wash the PATH.
> $ENV{'PATH'} = '/opt/gnu/bin:/usr/local/bin:/usr/bin';
> $ENV{'CDPATH'} = '';
> $ENV{'ENV'} = '';
>
> use IO::File;
> use CGI::Carp qw(carpout fatalsToBrowser carp);
^^^^^^^^^^^^^^^
Bye bye exception handling.
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: debuggers
Posted by "Bruce W. Hoylman" <bh...@qwest.com>.
>>>>> "Dave" == Dave Rolsky <au...@urth.org> writes:
Dave> On Thu, 7 Dec 2000, martin langhoff wrote:
>> I wonder how do those hardcore guys that develop using handlers
>> debug. Mhhh. They must write 'perlfect' code, I guess, and/or
>> understand those cryptic debuggers ...
Dave> I just do a lot of debugging via warn statements and looking
Dave> at the error logs.
My BEGIN block looks like this. I realize IO is rather bulky, but I
like it and the environment I'm in isn't *that* busy where it makes a
significant impact.
BEGIN {
# Wash the PATH.
$ENV{'PATH'} = '/opt/gnu/bin:/usr/local/bin:/usr/bin';
$ENV{'CDPATH'} = '';
$ENV{'ENV'} = '';
use IO::File;
use CGI::Carp qw(carpout fatalsToBrowser carp);
use Savvy::Conf qw(:WWWBasic);
my $log = 1;
my $logfile = "/www/cgi-logs/cgi-log";
if ($log) {
my $LOG = IO::File->new(">> $logfile") or
Savvy::Conf::cab("Unable to open $logfile for writing: $!\n");
# Dupe STDERR. Original is SAVEERR.
carpout($LOG);
}
}
Then I 'tail -f' the $logfile, the Apache server error_log, and watch
watever comes to the broswer due to the fatalsToBrowser. Works well for
me.
The '$r->log_reason' finds a home in my code as well.
Plus, I *always* use '-w' and '-T' and get them cleanly working during
development phases, although I shut them off for actual deployment.
Peace.
Re: debuggers
Posted by Dave Rolsky <au...@urth.org>.
On Thu, 7 Dec 2000, martin langhoff wrote:
> I wonder how do those hardcore guys that develop using handlers debug.
> Mhhh. They must write 'perlfect' code, I guess, and/or understand those
> cryptic debuggers ...
I just do a lot of debugging via warn statements and looking at the error
logs.
-dave
/*==================
www.urth.org
We await the New Sun
==================*/
Re: debuggers
Posted by clayton cottingham <cl...@marketingchallenge.com>.
Perrin Harkins wrote:
>
> On Thu, 7 Dec 2000, martin langhoff wrote:
> > I've always considered mod_perl to be completely debugger-unfriendly.
> > That's why I write modules that I can test from a standard script, and
> > then call those modules from Embperl pages or Registry scripts.
>
> Apache::Debug works. It's almost exactly the same as debugging a standard
> script.
>
>
i got it running once on our dev box and then no go ever since then
but yes it is sweet!
> I wonder how do those hardcore guys that develop using handlers debug.
> > Mhhh. They must write 'perlfect' code, I guess, and/or understand those
> > cryptic debuggers ...
>
> Do not be afraid of the command line...
>
> The Perl debugging shell is really not so hard if you give it a chance.
> I've taught a number of people here how to use it. I'm always amazed that
> more people don't use tools like the debugger and the profiler. They're
> life savers.
>
> - Perrin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: modperl-unsubscribe@apache.org
> For additional commands, e-mail: modperl-help@apache.org
Re: debuggers
Posted by Perrin Harkins <pe...@primenet.com>.
On Thu, 7 Dec 2000, martin langhoff wrote:
> I've always considered mod_perl to be completely debugger-unfriendly.
> That's why I write modules that I can test from a standard script, and
> then call those modules from Embperl pages or Registry scripts.
Apache::Debug works. It's almost exactly the same as debugging a standard
script.
> I wonder how do those hardcore guys that develop using handlers debug.
> Mhhh. They must write 'perlfect' code, I guess, and/or understand those
> cryptic debuggers ...
Do not be afraid of the command line...
The Perl debugging shell is really not so hard if you give it a chance.
I've taught a number of people here how to use it. I'm always amazed that
more people don't use tools like the debugger and the profiler. They're
life savers.
- Perrin
Re: debuggers
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 7 Dec 2000, martin langhoff wrote:
> Perrin Harkins wrote:
> >
> > I don't know how easy it is to make it play with
> > mod_perl though. Apache::Debug normally just dumps you into the shell
> > debugger. Maybe setting an environment variable would do it.
> >
>
> I've always considered mod_perl to be completely debugger-unfriendly.
> That's why I write modules that I can test from a standard script, and
> then call those modules from Embperl pages or Registry scripts.
>
> I wonder how do those hardcore guys that develop using handlers debug.
> Mhhh. They must write 'perlfect' code, I guess, and/or understand those
> cryptic debuggers ...
Personally I've always relied on sending debug messages to the log, and
then staring at the code for a few minutes/months.
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: debuggers
Posted by martin langhoff <ma...@scim.net>.
Perrin Harkins wrote:
>
> I don't know how easy it is to make it play with
> mod_perl though. Apache::Debug normally just dumps you into the shell
> debugger. Maybe setting an environment variable would do it.
>
I've always considered mod_perl to be completely debugger-unfriendly.
That's why I write modules that I can test from a standard script, and
then call those modules from Embperl pages or Registry scripts.
I wonder how do those hardcore guys that develop using handlers debug.
Mhhh. They must write 'perlfect' code, I guess, and/or understand those
cryptic debuggers ...
martin
Re: debuggers
Posted by Perrin Harkins <pe...@primenet.com>.
On Thu, 7 Dec 2000, martin langhoff wrote:
> All this talk about DDD is making me wonder if there is a suitable
> (graphical) Perl IDE that I can run on Gnome.
Last time I tried them, I found ptkdb a bit nicer than DDD, mostly because
DDD was kind of slow. I don't know how easy it is to make it play with
mod_perl though. Apache::Debug normally just dumps you into the shell
debugger. Maybe setting an environment variable would do it.
- Perrin
Re: debuggers
Posted by martin langhoff <ma...@scim.net>.
Perrin,
In fact, I've always been coding from NT machines -- for my *nix
servers, of course. Now the ActiveState people are building a
cross-platform and cross-language IDE that integrates with perldebug
nicely -- or so it seems. I'm actually starting to like it -- it's built
on top of mozilla, so its a bit bloated and slow -- but I like it, just
like mozilla ;)
And, on top of that, it's called Komodo, and that means 'comfort' -- in
Spanish, that is.
All this talk about DDD is making me wonder if there is a suitable
(graphical) Perl IDE that I can run on Gnome. If there's one, maybe I'll
change my dev workstation from an NT box to RHLinux 6.1 ...
Well, there's Komodo, for instance ;)
martin
pd: of course, in Spanish you'd say cómodo -- with a stress on the first
o.
debuggers
Posted by Perrin Harkins <pe...@primenet.com>.
On Thu, 7 Dec 2000, martin langhoff wrote:
> [1] Having grown up in a cushioned, fancy VB 3.0 IDE, I still
> find both vi, emacs and textmode debug too harsh for me.
You could try ptkdb or DDD for GUI debugging.
- Perrin
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Posted by martin langhoff <ma...@scim.net>.
"Aaron E. Ross" wrote:
> 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
I'd say that load balancing is too involved an issue to make it
into a
package, I'd leave it aside, as anyone actually needing it will be
certainly building his apaches manually.
And I would also leave the IDE aside, (although I think I have a
great
candidate[1]). IDEs are very personal things, and users are sometimes
very attached to theirs ... so much that merely installing an IDE is
sometimes an offence.
[1] Having grown up in a cushioned, fancy VB 3.0 IDE, I still
find both
vi, emacs and textmode debug too harsh for me. So I've been toying with
the early releases of Komodo
(http://www.ActiveState.com/Products/Komodo.html) and I actually like it
although its far from finished. Has anyone used/tested it?
martin
Re: Smart installing (Re: mod_perl advocacy project
resurrection)
Posted by Gunther Birznieks <gu...@extropia.com>.
I don't mean to naysay it, but this is going to start getting quite binary
specific. I guess you could maintain an RPM for Linux, but beyond that it
seems quite difficult. And even if you maintain it as an RPM for Linux, do
you make your own Perl distro with it or use RedHat's crappy distro?
Or?
On Linux I think installing Apache with Mod_Perl is almost trivial. What
might be needed is some shell scripts that automate the process to
accompany the readme's.
It's the other platforms that are a bear for me personally. But if you made
a binary for every platform. Wah! So hard.
I think you are better off not touching the binary stuff and sticking to
writing a traditional app framework that is not dependent on mod_perl, is
not dependent on any database, but can make use of such things. Then,
people can upgrade as they see fit.
Later,
Gunther
At 03:54 PM 12/6/00 -0500, Aaron E. Ross wrote:
>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: modperl-unsubscribe@apache.org
>For additional commands, e-mail: modperl-help@apache.org
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
eXtropia - The Web Technology Company
http://www.extropia.com/
Re: Smart installing (Re: mod_perl advocacy project
resurrection)
Posted by Gunther Birznieks <gu...@extropia.com>.
At 02:01 PM 12/6/00 -0800, brian moseley wrote:
>On Wed, 6 Dec 2000, Aaron E. Ross wrote:
>
> > 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.
>
>perhaps take a look at AO - it's a good start at a servlet
>engine that packages at least a few of the items you've
>highlighted. i'd love to participate in a project that uses
>AO, backhand, an o/r mapping tool, and other components to
>provide an out of the box 2-tier system. i'd also love to
>see an "enterprise" or 3-tier version of same. let's
>organize!
>
>i suppose i should get the AO sourceforge site up and
>running eh?
To be fair with regards to application toolkits, there's also
SmartWorker.org and our eXtropia stuff. :)
We already have 3-tier solutions working on our apps using SOAP as the
primary marshalling protocol acting as a proxy to Java versions of our
objects. This allows us to do intelligent database and rowset result
caching on a multithreaded Java server while the front-end Perl apps just
marshall calls in to that server using SOAP.
I do wish there were more app toolkits out there as it would create more
choice and provide some good experiments about what's a good mechanism for
developing apps.
eg I found looking at SmartWorker very interesting to see what I liked and
did not like and Microsoft ASP for what I liked and didn't like. Of course,
I disliked most of Microsoft ASP, but I did like ADO, so we stole the
concept and implemented it in Perl and Java (JDO is still not out yet
officially from JavaSoft).
Of course, app toolkits are tough to write, and then you have to write or
find people to write real apps on top of them to validate the design work.
Later,
Gunther
Re: Smart installing (Re: mod_perl advocacy project
resurrection)
Posted by Gunther Birznieks <gu...@extropia.com>.
At 07:12 AM 12/7/00 -0500, barries wrote:
>On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote:
> > the only thing I would add is DBI and DBD:::CSV,
>
>No joins. Therefore not very useful.
Actually joins are over-rated for most simple apps. It's very easy to make
a calendar, address book and other common apps w/o joins.
With that said though, DBD::CSV has some serious short-comings. Not the
least of which is the lack of file locking.
But because of the popularity of flatfile databases for newbies, that's why
in our application toolkit we ended up making an abstraction that sits
about more than just DBI -- native flatfiles, XML files, LDAP, SOAP, etc..
called DataSource with its own query language roughly similar in concept to
Microsoft's ADO. Love it or hate it (most people who have used it do love
it or hate it).
> > you get a basic prototyping
> > db and you can add other drivers as you need them. And the package
> needs to
> > specify the version of gcc it was built with, so you can add dso's and/or
> > perl XS modules.
>
>If you're doing that, you've graduated yourself to recompiling the whole
>kit and kabootle.
That's probably true.
One thing that would make things much easier for mod_perl is to get the DSO
mechanism fully working. A lot of ISPs compile apache with DSO support, and
so making mod_perl work well with DSO would help so that you don't have to
ship a pre-compiled apache.
Anyway, I think people need binary distributions really. Make is too
complicated for a lot of newbies.
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Posted by Marc Spitzer <ms...@optonline.net>.
Thanks for pointing that out, or I could just use compress. As far as the
$$$ goes you need to spend money to start a business lets see if there is a
market first. Another thing we could add is interbase to the list or break
it up into 3 or more packages that are integrated out of the box, call it
rev 2( with no rev 1 yet). here is what I see if I do that later:
1: apache/perl/modperl/dbi/dbd for all supported db and there client
code/ldap client
2: open ldap/berkelydb
3: postgress
4: interbase
5: mysql
... more stuff here
N: auxiliary package gcc/gmake and what ever else
these components would all have to work out of the box with each other, I
install 1 on my web server and 2 on my ldap box and it works or I install
both on 1 box and it works.
Everything should go under 1 directory
/opt/something/(apache|ldap|postgress) etc.
This will be a good deal of not fun work though.
The way to idiot proof something is to not listen to idiots, this is where
it goes and that is the end of it. Give people a list of where each default
is web root, datafiles for interbase postgres openldap in a step by step pre
install guide and have them start at step 1 and go to step N and you have
installed the package(s) you need.
marc
----- Original Message -----
From: Jimi Thompson <jt...@link.com>
To: Marc Spitzer <ms...@optonline.net>; <mo...@apache.org>
Sent: Thursday, 7. December 2000 13:40
Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection)
> Marc,
>
> In order to be kind to newbie's, you will need to mention tar and gnu zip
which
> don't come standard on some flavors of Unix. In my case Solaris 2.6 only
has
> tar. Zip must be installed. Also, you are going to need to at least
point them
> to documentation.
>
> Maybe we could make extra $$$ selling tech support for your bundle (a la
Red
> Hat)??? The extra cabbage could go to buying ads.
>
> I think the goal of the "total installation" should be something akin to
M$
> Office if you are aiming at the corporate/business user. PHB's like
things that
> they feel like they can control.
>
> I have no idea how you could idiot proof this, though, unless you set LOTS
of
> defaults.
>
> Marc Spitzer wrote:
>
> > I don't know about that, getting the correct version of perl, mod_perl.
> > apache and all the preconfigured modules together and configuring
cpan... as
> > apposed to installing DBD::Postgres(uses XS), hell I could stick gcc
> > postgres and open ldap in the package. krap I just gave my self more
work.
> > Here is the list so far:
> > apache
> > postgres
> > openldap
> > perl
> > mod_perl
> > libnet
> > configure CPAN
> > DBI
> > DBD::CSV
> > DBD:Pg
> > BerkleyDB 3.x (openLDAP), this could cause a problem 2.x in in some
linuxs
> > glibc, I think
> > berkelyDB perl module
> > GCC
> > gmake
> >
> > This gives you a nice base system and everything you need to add stuff
to
> > it.
> >
> > Now I have 2 questions for the list:
> > 1: is this a good idea or a waste of my time
> > 2: did I forget anything
> >
> > marc
> >
> > ----- Original Message -----
> > From: barries <ba...@slaysys.com>
> > To: Marc Spitzer <ms...@optonline.net>
> > Cc: mod_perl list <mo...@apache.org>; Marc Spitzer <ma...@cv.net>
> > Sent: Thursday, 7. December 2000 7:12
> > Subject: Re: Smart installing (Re: mod_perl advocacy project
resurrection)
> >
> > > On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote:
> > > > the only thing I would add is DBI and DBD:::CSV,
> > >
> > > No joins. Therefore not very useful.
> > >
> > > > you get a basic prototyping
> > > > db and you can add other drivers as you need them. And the package
> > needs to
> > > > specify the version of gcc it was built with, so you can add dso's
> > and/or
> > > > perl XS modules.
> > >
> > > If you're doing that, you've graduated yourself to recompiling the
whole
> > > kit and kabootle.
> > >
> > > - Barrie
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: modperl-unsubscribe@apache.org
> > For additional commands, e-mail: modperl-help@apache.org
>
> --
> Jimi Thompson
> Web Master
> L3 communications
>
> "It's the same thing we do every night, Pinky."
>
>
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Posted by Jimi Thompson <jt...@link.com>.
Marc,
In order to be kind to newbie's, you will need to mention tar and gnu zip which
don't come standard on some flavors of Unix. In my case Solaris 2.6 only has
tar. Zip must be installed. Also, you are going to need to at least point them
to documentation.
Maybe we could make extra $$$ selling tech support for your bundle (a la Red
Hat)??? The extra cabbage could go to buying ads.
I think the goal of the "total installation" should be something akin to M$
Office if you are aiming at the corporate/business user. PHB's like things that
they feel like they can control.
I have no idea how you could idiot proof this, though, unless you set LOTS of
defaults.
Marc Spitzer wrote:
> I don't know about that, getting the correct version of perl, mod_perl.
> apache and all the preconfigured modules together and configuring cpan... as
> apposed to installing DBD::Postgres(uses XS), hell I could stick gcc
> postgres and open ldap in the package. krap I just gave my self more work.
> Here is the list so far:
> apache
> postgres
> openldap
> perl
> mod_perl
> libnet
> configure CPAN
> DBI
> DBD::CSV
> DBD:Pg
> BerkleyDB 3.x (openLDAP), this could cause a problem 2.x in in some linuxs
> glibc, I think
> berkelyDB perl module
> GCC
> gmake
>
> This gives you a nice base system and everything you need to add stuff to
> it.
>
> Now I have 2 questions for the list:
> 1: is this a good idea or a waste of my time
> 2: did I forget anything
>
> marc
>
> ----- Original Message -----
> From: barries <ba...@slaysys.com>
> To: Marc Spitzer <ms...@optonline.net>
> Cc: mod_perl list <mo...@apache.org>; Marc Spitzer <ma...@cv.net>
> Sent: Thursday, 7. December 2000 7:12
> Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection)
>
> > On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote:
> > > the only thing I would add is DBI and DBD:::CSV,
> >
> > No joins. Therefore not very useful.
> >
> > > you get a basic prototyping
> > > db and you can add other drivers as you need them. And the package
> needs to
> > > specify the version of gcc it was built with, so you can add dso's
> and/or
> > > perl XS modules.
> >
> > If you're doing that, you've graduated yourself to recompiling the whole
> > kit and kabootle.
> >
> > - Barrie
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: modperl-unsubscribe@apache.org
> For additional commands, e-mail: modperl-help@apache.org
--
Jimi Thompson
Web Master
L3 communications
"It's the same thing we do every night, Pinky."
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Posted by Marc Spitzer <ms...@optonline.net>.
I don't know about that, getting the correct version of perl, mod_perl.
apache and all the preconfigured modules together and configuring cpan... as
apposed to installing DBD::Postgres(uses XS), hell I could stick gcc
postgres and open ldap in the package. krap I just gave my self more work.
Here is the list so far:
apache
postgres
openldap
perl
mod_perl
libnet
configure CPAN
DBI
DBD::CSV
DBD:Pg
BerkleyDB 3.x (openLDAP), this could cause a problem 2.x in in some linuxs
glibc, I think
berkelyDB perl module
GCC
gmake
This gives you a nice base system and everything you need to add stuff to
it.
Now I have 2 questions for the list:
1: is this a good idea or a waste of my time
2: did I forget anything
marc
----- Original Message -----
From: barries <ba...@slaysys.com>
To: Marc Spitzer <ms...@optonline.net>
Cc: mod_perl list <mo...@apache.org>; Marc Spitzer <ma...@cv.net>
Sent: Thursday, 7. December 2000 7:12
Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection)
> On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote:
> > the only thing I would add is DBI and DBD:::CSV,
>
> No joins. Therefore not very useful.
>
> > you get a basic prototyping
> > db and you can add other drivers as you need them. And the package
needs to
> > specify the version of gcc it was built with, so you can add dso's
and/or
> > perl XS modules.
>
> If you're doing that, you've graduated yourself to recompiling the whole
> kit and kabootle.
>
> - Barrie
>
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Posted by barries <ba...@slaysys.com>.
On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote:
> the only thing I would add is DBI and DBD:::CSV,
No joins. Therefore not very useful.
> you get a basic prototyping
> db and you can add other drivers as you need them. And the package needs to
> specify the version of gcc it was built with, so you can add dso's and/or
> perl XS modules.
If you're doing that, you've graduated yourself to recompiling the whole
kit and kabootle.
- Barrie
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Posted by Marc Spitzer <ms...@optonline.net>.
the only thing I would add is DBI and DBD:::CSV, you get a basic prototyping
db and you can add other drivers as you need them. And the package needs to
specify the version of gcc it was built with, so you can add dso's and/or
perl XS modules. I am more a sys admin then a programmer but I would be
willing to build a Solaris package for this. IFF I find the time I would
also look into doing it for FreeBSD and possibility OpenBSD, they both use
the same packaging standard. I will not have time to start this for about 2
weeks though. Please keep in mind that I have no experience with mod_perl
so I would need some noble soul to test the krap out of it.
marc spitzer
----- Original Message -----
From: kevin montuori <mo...@arrakisplanet.com>
To: Aaron E. Ross <ro...@coreference.com>
Cc: Dave Rolsky <au...@urth.org>; brian moseley <bc...@maz.org>; mod_perl
list <mo...@apache.org>
Sent: Wednesday, 6. December 2000 17:17
Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection)
> >>> Aaron E Ross writes:
>
>
> aer> the possibility of being able to untar one package to get
> aer> mod_perl w/ persistent db connections, [&c.] is very glamorous!
>
> agreed. but fundamentally impossible. what database are you
> going to provide persistent connections to? mysql? not on my
> solaris box you're not, unless you're going to include mysql in
> your distribution. besides, i want sybase. ok, so skip the
> database and use DBM files, gdbm's everywhere, right? again,
> not (standard, anyway) on solaris. so, package up gdbm too.
>
> you can see where that's going.
>
> i think providing a mod_perl framework in which applications
> can be written is a noble idea. i think recommending a
> particular solution is great -- lots of people who hack
> mod_perl day in and day out can't keep up with all the new
> modules/products, a summary of what's available would be useful
> to new programmers and veterans alike.
>
> i also think that this is a case of walking before running:
> putting together a summary document of mod_perl development
> environments (mason, axkit, ao, &c.) has (to the best of my
> knowledge) eluded us so far, the notion that we could bundle
> some together and get them to work is pie in the sky thinking.
> whoever said that packaging all this stuff together (i think it
> was MS or BM) is extremely difficult is absolutely correct.
>
> in my current shop, we have enough trouble creating packages
> that work on both solaris 6 and 8 without any modification, and
> we're pretty good at this sort of thing.
>
> bundling *just* mod_perl and apache in one package that can be
> build and installed by pushing a button seems like an excellent
> short term goal. for some people just starting out, you'd be a
> folk hero if you provided just this.
>
> (i'm not down on the idea really, but if packaging is going to
> be considered as a form of advocacy, it'd be nice if we
> attacked it in easy to digest chunks. starting with the two
> packages, and perhaps a couple sample applications and moving
> on from there.)
>
>
> aer> except for transaction management, which is apparently of
> aer> questionable value,
>
> i don't think anyone is claiming that transaction management is
> of questionable value -- when you need it, you need it; there's
> no substitute. (unless you consider reconciling databases by
> hand a substitute.)
>
> cheers,
> k.
>
>
> --
> kevin montuori
>
> support independent booksellers -- http://www.booksense.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: modperl-unsubscribe@apache.org
> For additional commands, e-mail: modperl-help@apache.org
>
>
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Posted by "Aaron E. Ross" <ro...@coreference.com>.
at a time earlier than now, kevin montuori wrote:
> >>> Aaron E Ross writes:
>
>
> aer> the possibility of being able to untar one package to get
> aer> mod_perl w/ persistent db connections, [&c.] is very glamorous!
>
> agreed. but fundamentally impossible. what database are you
> going to provide persistent connections to? mysql? not on my
> solaris box you're not, unless you're going to include mysql in
> your distribution. besides, i want sybase. ok, so skip the
> database and use DBM files, gdbm's everywhere, right? again,
> not (standard, anyway) on solaris. so, package up gdbm too.
Well, I see the problem, but ... when you install J2EE or WebSphere, you
don't actually get DB2 or Oracle installed too. You do however, get
an interface to a connection pooling mechanism, all you have to do is
code it ( and maybe configure it ). I'm imagining the same thing. If
you need a feature, turn it on. No CPAN, Compilation, etc ...
Rather than having to install Apache::Session,DBI,DBD each time, it should
be ready to go with whatever database you are using.. or not at all.
Providing compiled version of DBD drivers is harder, but not necessarily
in the scope of this project. Oracle provides their own jdbc drivers, not
Sun and yet it is still a easier install.
I agree that providing a complete working, just add water environment is
impossible, but providing the groundwork for one is not. So let's start,
as you suggested, with two goals
1) bundling working versions of apache and mod_perl
2) providing summaries and descriptions of mod_perl development
environments.
Aaron
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Posted by kevin montuori <mo...@arrakisplanet.com>.
>>> Aaron E Ross writes:
aer> the possibility of being able to untar one package to get
aer> mod_perl w/ persistent db connections, [&c.] is very glamorous!
agreed. but fundamentally impossible. what database are you
going to provide persistent connections to? mysql? not on my
solaris box you're not, unless you're going to include mysql in
your distribution. besides, i want sybase. ok, so skip the
database and use DBM files, gdbm's everywhere, right? again,
not (standard, anyway) on solaris. so, package up gdbm too.
you can see where that's going.
i think providing a mod_perl framework in which applications
can be written is a noble idea. i think recommending a
particular solution is great -- lots of people who hack
mod_perl day in and day out can't keep up with all the new
modules/products, a summary of what's available would be useful
to new programmers and veterans alike.
i also think that this is a case of walking before running:
putting together a summary document of mod_perl development
environments (mason, axkit, ao, &c.) has (to the best of my
knowledge) eluded us so far, the notion that we could bundle
some together and get them to work is pie in the sky thinking.
whoever said that packaging all this stuff together (i think it
was MS or BM) is extremely difficult is absolutely correct.
in my current shop, we have enough trouble creating packages
that work on both solaris 6 and 8 without any modification, and
we're pretty good at this sort of thing.
bundling *just* mod_perl and apache in one package that can be
build and installed by pushing a button seems like an excellent
short term goal. for some people just starting out, you'd be a
folk hero if you provided just this.
(i'm not down on the idea really, but if packaging is going to
be considered as a form of advocacy, it'd be nice if we
attacked it in easy to digest chunks. starting with the two
packages, and perhaps a couple sample applications and moving
on from there.)
aer> except for transaction management, which is apparently of
aer> questionable value,
i don't think anyone is claiming that transaction management is
of questionable value -- when you need it, you need it; there's
no substitute. (unless you consider reconciling databases by
hand a substitute.)
cheers,
k.
--
kevin montuori
support independent booksellers -- http://www.booksense.com
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Posted by brian moseley <bc...@maz.org>.
On Wed, 6 Dec 2000, Aaron E. Ross wrote:
> 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.
perhaps take a look at AO - it's a good start at a servlet
engine that packages at least a few of the items you've
highlighted. i'd love to participate in a project that uses
AO, backhand, an o/r mapping tool, and other components to
provide an out of the box 2-tier system. i'd also love to
see an "enterprise" or 3-tier version of same. let's
organize!
i suppose i should get the AO sourceforge site up and
running eh?
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Posted by Dave Rolsky <au...@urth.org>.
On Wed, 6 Dec 2000, Aaron E. Ross wrote:
> 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!
Well, while I'd like to masses to speak my name in legend and song, I've
also got a lot on my plate ;)
Seriously, I'm less interested in a unified package (I think Brian is
working on that) than an intelligent system for doing configuration of
modules/apps.
For example, for one project I'm working on, I've had to do a fair amount
of work to get it to try to find an existing mod_perl enabled Apache
server and then to check whether or not the server is the right version of
Apache and mod_perl.
This kind of work would probably be useful in a more generic form. Some
of this work is already in the Apache::test module, which can analyze a
server and its configuration and find some useful info. Enhancing this
module to really be able to give a lot of details about an existing
install would be very useful.
This would certainly be handy for the all in one system you describe
(which is what Brian's aiming at for AO, if I'm not mistaken) but also for
any other large mod_perl using app.
Similarly, a mechanism for packaging tests to be done against a database
would be useful (something I've worked on for Alzabo).
Like I said, I really need to examine cons and see if it can help with all
this. The problem being that most people don't have cons installed
(although it can always be included in a package).
-dave
/*==================
www.urth.org
We await the New Sun
==================*/
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Posted by "Aaron E. Ross" <ro...@coreference.com>.
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.
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Posted by Benjamin Trott <be...@rhumba.pair.com>.
> Perhaps part of this is that we simply need smarter configure/install
> methods.
> ...
> 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've been dealing w/ very similar issues in work I'm doing. I've got:
* Perl modules
* command line tools
* database tables
* data files
* custom configuration
* other open-source distributions
and more, and it's all got to be installed in the right place, and the Right
Thing has to happen if some pieces are already installed, etc.
My "solution", so far, is a custom install script. Rather than trying to
hack everything into MakeMaker and make it work through some deep magic, I'm
writing an install script that's a layer above the MakeMaker stuff: I still
let MakeMaker do its job w/ the Perl modules, regression tests, etc.
But so far I've ended up writing my own code for everything else. And that's
partly why it's not done yet. :)
I also mean to investigate cons.
bye,
Ben