Re: modperl growth
Paul DuBois [EMAIL PROTECTED] writes: At 11:02 + 2/3/02, Dave Hodgkinson wrote: Paul DuBois [EMAIL PROTECTED] writes: Mac OS X includes Apache, and mod_perl works there, too. That's another group of potential new mod_perl-ized servers. I think all the recent RedHats come with mod_perl as a DSO by default. I just looked on a RH 7.2 machine. It has the AddModule line in the default httpd.conf, but no mod_perl.so in the modules directory. OK try: ps wwaux | grep httpd Does it have -DHAVE_PERL? -- Dave Hodgkinson, Wizard for Hire http://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Interim Technical Director, Web Architecture Consultant for hire
Re: [OT] Re: mod_perl Developer's Cookbook (and Amazon)
Paul Lindner [EMAIL PROTECTED] wrote: I'm against frivolous patents myself. It harms the industry and could even be detrimental to mod_perl or Apache if either is found to infringe upon such a patent. That indeed is the problem. Now that the FTC has been scared (or bought?) off, this is the *obvious* move for a large company to try and cut off the air supply of the open source movement. However, please read the following articles before you boycott. The first is an open letter from Jeff Bezos, the second is a fairly lengthy article on the subject by Tim O'Reilly. http://www.amazon.com/exec/obidos/subst/misc/patents.html http://www.oreilly.com/ask_tim/patent_reform_0300.html I read them some time ago, and re-read them again, and I'm still not impressed. Many companies take out software patents, but they claim they're for defensive purposes, so that they can use them to counter-sue. Amazon is the first case I've heard of where someone used them offensively. Jeff Bezos, to my ear, is just making some noises to put the crowd to sleep. He promises to chat with some congressman and that makes it all better? To me the whole point of boycotts is to provide some pressure to behave ethically even when it's not (yet?) legally mandated. Mike808 [EMAIL PROTECTED] wrote: And Barnes and Noble deserves its fair share of disgust for filing counter patent-infringement suits. I'm no fan of Barnes and Noble, but a counter-suit is a counter-suit... the other guy was already playing dirty, before they started in with it. And since BN owns Fatbrain, Yeah, I know, and am not happy about it, but at least it puts a dollar into the pocket of Amazons victim. so BookPool is my vendor of choice currently for price-conscious book shopping. Thanks, I'll look into that one.
Speed of downloading problem.
Hello, I have Apache/mod_perl installed on a NT box, and I am allowing customers to do downloads of High-Resolution assets. My problem is the speed of downloads is about 1/3 slower than the same box running IIS. IT dept, has confirmed that the network is not the issue, and we have ran tests for the past week. The conclusion we have drawn is for some reason, when we point to a static HTML file on the docroot of the Apache running mod-perl server that it takes 2/3 times longer to download a file than on IIS. The test is taking a 50mb file and placing it in the doc root of the IIS and Apache/htdocs. Then just having a href link pointing to it. We have ruled out the firewall and any networking. Does anyone have any clues what to try? One thought here was to go to 2.0, but we don't know if that will screw up the mod-perl that is built for the Apache 1.3.20 and Ron Savages mod_perl binary. Any info would certainly be appreciated. Scott Purcell
Re: Make test issue with the URI module
Hi! On Sun, Feb 03, 2002 at 05:24:03PM -0800, Pierre Carette wrote: I am trying to install the latest version of Mod_perl (version 1.26) with Apache 1.3.23 on RedHat 7.2. When I tried the make test from the mod_perl installation I had an error saying that the module URI couldn't be found. I then downloaded and installed the URI module from cpan.org: URI-1.18 and now I get the following error: /usr/bin/perl t/TEST 0 Can't locate object method new via package URI::URL at ../blib/lib/Apache/te st.pm line 252. I ran into the same problem yesterday. I 'solved' it by adding use URI::URL; to blib/lib/Apache/test.pm Does anyone know why this fails or how to fix it properly? -- D_OMM + http://domm.zsi.at -+ O_xyderkes | neu: Arbeitsplatz | M_echanen | http://domm.zsi.at/d/d162.html | M_asteuei ++
mod_perl, OpenPGP Math::Pari
OK, this has got me stumped.. so it just has to be something obvious.. I am attemting to use Crypt::OpenPGP to encrypt some data. To do this I need to generate some keys.. (ok that's all obvious too..get to the point, J) On my development server everything runs fine producing useable public private keys. I've added a subroutine to my lil web system (running on mod_perl) that takes the required arguements and feeds them to OpenPGP's keygen method. On our production server this dies with the message [error] PARI: *** incorrect type in comparison. at /usr/lib/perl5/site_perl/5.6.1/Crypt/Primes.pm line 683. Now what's really got me stumped, is feeding the same sub with the same arguements in an independant perl script run from the command line on the production (and development) server runs fine and produces usable public private keys. My only guess is that somehow mod_perl on the production server is using a different library of modules than perl run from the command line is using but I can't believe that I wouldn't have had troubles long ago if that were the case. Anyone? any clues on where to start looking? Development Apache/1.3.20 (Unix) mod_perl/1.25 Production Apache/1.3.20 (Unix) mod_perl/1.26 cheers -- J Web Developer Eight Degrees Off Centre http://www.eightdegrees.com.au/
Re: weird problem. Lost of the POST data
Hi: some days ago I wrote to ask for this problem: The CGI.pm (sometimes) could not receive the POST data. I tried all you recomended me here in the list. But I still had the problem. Finally I decide to kick out CGI.pm and start to use the old cgi-lib.pl. But I still had the same problem. Then I turnet to Apache::Request, and since I use it, I've never had the same problem. I just tell you because perphaps somebody may have the same problem. I don't really understan if the problem is in mod_perl, in Apache, in Templat Toolkit, in my ultrasecure patched kernel, in CGI.pm, but the point is that Apache::Request seems not to loose any post data :-? Thank you all. Oscar Serrano.
Re: Speed of downloading problem.
I have Apache/mod_perl installed on a NT box, and I am allowing customers to do downloads of High-Resolution assets. My problem is the speed of downloads is about 1/3 slower than the same box running IIS. Can you post your httpd.conf? Or at least the parts of it about threads and processes? It is possible that Apache is just not that fast on NT. NT support is experimental in the 1.3 series. One thought here was to go to 2.0 You can't run mod_perl 1.x on Apache 2.0. Another thing you could try is having multiple servers. One could handle static requests and proxy the dynamic ones to mod_perl. I don't know if IIS knows how to do this or not, but there's probably something available for NT that does it. - Perrin
Re: [OT] Re: mod_perl Developer's Cookbook (and Amazon)
On Mon, 4 Feb 2002, Joe Brenner wrote: so BookPool is my vendor of choice currently for price-conscious book shopping. Thanks, I'll look into that one. Or better yet, go to www.booksense.com, enter your zip code, and shop online at an independent local book-seller near you. It might be a little more expensive but chances are they'll carry whatever book you want and it will ship quickly. And you'll be supporting a locally owned small business, owned by actual human beings, not some giant corporate machine. -dave /*== www.urth.org we await the New Sun ==*/
Re: weird problem. Lost of the POST data
On Mon, 4 Feb 2002, Oscar Serrano wrote:
some days ago I wrote to ask for this problem: The CGI.pm (sometimes) could
not receive the POST data. I tried all you recomended me here in the list.
But I still had the problem. Finally I decide to kick out CGI.pm and start
to use the old cgi-lib.pl. But I still had the same problem. Then I turnet
to Apache::Request, and since I use it, I've never had the same problem.
I just tell you because perphaps somebody may have the same problem. I
don't really understan if the problem is in mod_perl, in Apache, in Templat
Toolkit, in my ultrasecure patched kernel, in CGI.pm, but the point is that
Apache::Request seems not to loose any post data :-?
I had a similar problem a few days ago with a form processing engine I
developed with mod_perl Text::Template. It takes a sequence of states
out of a database and generates a 'wizard' to lead a user through a set of
forms for, say, an employment application, membership application, etc.
It uses a combination of CGI.pm for some of the high-level front end
stuff, and uses the Apache::* modules for the lower level stuff (cookies,
session management, etc). Anyway, I had this wierd bug that instead of
the straight sequence of forms, it would do the first form, then the
second, the the first again, then the third, then the first again, then
the fourth, and so on. POST data was either missing, or incomplete, or
was picking up values from several pages back.
I discovered what the problem was: I had a hash in one of my top-level
class files (the system is object-oriented) that was being used as a
global variable, a hash that had data that changed a lot. Bad juju with
mod_perl! Moving the hash into the class constructor and making sure it
got properly blessed into that class fixed the problem.
Another issue that can cause problems, especially using the OOP interface
to CGI.pm under mod_perl, is using a global CGI object and using it inside
of subroutines:
my $cgi = new CGI;
...
sendmail('A message');
...
sub send_mail {
my $msg = shift;
print $cgi-h1('Something');
print $cgi-p;
...
}
This will cause some wierd problems. The solution is to not use globals
inside your subroutine, but pass what you need into it:
sendmail($cgi, 'A Message');
sub send_mail {
my $q = shift;
my $msg = shift;
...
}
http://www.chapelperilous.net/
When the wind is great, bow before it;
when the wind is heavy, yield to it.
Re: modperl growth
On Saturday 02 February 2002 23:20, Matt Sergeant wrote: Wow, bizarre. Not sure why but the AxKit list has seen a massive spurt in traffic lately too. Perhaps due to the migration to xml.apache.org (well, just a link at the moment), but perhaps due to the above? Traffic is notoriously hard to predict. Maybe someone has just been asking a lot of questions, which in turn has brought others to ask more questions, as well as brought up subjects people had been wanting to investigate but had forgotten to post about, etc. However I'm always skeptical of such massive changes - perhaps more likely is a change in SecuritySpace's methodology? If that were the case it would affect other modules similarly. I went through a number of other modules, notably PHP, and the Java ones and there is no comparable change. The only other sharp increase was for mod_fastcgi, but it was merely a jump from 2.5 to 3% or something like that, nothing really comparable to the leap forward made by modperl. -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Change is inevitable except from a vending machine.
Re: modperl growth
one more guess - in the group of guesses. ;-) perhaps redhat or another popular distro is configuring standard with mod_perl (i use redhat, but i always hand select my packages). if this is the case, then the banner will show mod_perl, even if the user has no idea what it is, and it is not in use. the good news is, there is lots of mod_perl installed out there, so if more applications are created that use it, there is a bigger installed base capable of running them. cliff Robin Berjon wrote: For some reason, in December, it would seem that modperl just jumped ahead in market share (from 13% to nearly 20%). So given that people here are occasionally given to gloom and doom descriptions of the Perl/mod_perl world (there aren't as many people as before, the Java folks are taking over, etc.) I'd like to take this growth as well as modperl's general well doing (19.78% is a *huge* amount of people -- 600.000 servers, a fifth of the internet) as a very good sign that modperl is alive, kicking, and doing very well. Kudos to all ;-) -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
response code under Apache::Registry?
This is kind of a bizarre question, but I was wondering if it was technically possible to set the response code of a script running under Apache::Registry. The way I usually see it being set is the return value of the handler routine, but is there any way to set it? Peter Beardsley Appropriate Solutions, Inc. [EMAIL PROTECTED]
Re: response code under Apache::Registry?
Peter Beardsley wrote: This is kind of a bizarre question, but I was wondering if it was technically possible to set the response code of a script running under Apache::Registry. The way I usually see it being set is the return value of the handler routine, but is there any way to set it? the way Apache::Registry works is that you have to set $r-status. Apache::Registry, behind the scenes, will return $r-status as the handler return code and reset the official status. for instance, it's typical for redirects to see $r-headers_out-set(Location = '/foo.html'); $r-status(REDIRECT); return REDIRECT; in this case, the return REDIRECT actually does nothing - it's the call to $r-status that does the work. HTH --Geoff
Re: modperl growth
___cliff rayman___ [EMAIL PROTECTED] writes: one more guess - in the group of guesses. ;-) perhaps redhat or another popular distro is configuring standard with mod_perl (i use redhat, but i always hand select my packages). if this is the case, then the banner will show mod_perl, even if the user has no idea what it is, and it is not in use. the good news is, there is lots of mod_perl installed out there, so if more applications are created that use it, there is a bigger installed base capable of running them. And if the Slashcode were as easy to install and customise as phpnuke... ;-) Hmmmactually, there's half a point buried in there. -- Dave Hodgkinson, Wizard for Hire http://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Interim Technical Director, Web Architecture Consultant for hire
Re: modperl growth
On 4 Feb 2002, Dave Hodgkinson wrote: And if the Slashcode were as easy to install and customise as phpnuke... For OSCON (and hopefully YAPC too), I've submitted a talk on using Module::Build (an ExtUtils::MakeMaker replacement) for modules and using it to build an application installer. Its not _that_ hard, and using Module::Build makes it a lot easier. When Matt Sergeant and I were working on (formerly) O'Reilly's WebBoard for Unix, we built an interactive command-line installer that could do the following: - Install Apache and mod_perl, or use an existing installation. - Install all the needed modules, template files, images, etc. - Set up a new database in your RDBMS of choice (MySQL, Postgres, Sybase, or Oracle) though the Sybase and Oracle choices weren't 100% automated (they are just too complex). Nowadays, I'd use Alzabo, which can also intelligently handle upgrading old versions of a schema (its not quite 100% perfect but its pretty good). - Insert various default values into your DB, if they weren't already there. At this point, you simply (re-)started your Apache w/mod_perl and you were ready to go. You had an admin account you logged in with and could start creating boards and such. It was a lot of work but its not _that_ hard. Perl definitely needs more out of tarball/box/whatever install-able apps and I'd like to help people get there. Alzabo is pretty close, though it still requires you to hand-modify your httpd.conf. I'm not sure how on-topic this is anymore, though I don't think creating a separate list would exactly help at this point. -dave /*== www.urth.org we await the New Sun ==*/
RE: modperl growth
Many cobalt boxes come running mod_perl by default. perhaps if people have been deploying a lot of these things lately it could have made an impact. HEAD / HTTP/1.0 HTTP/1.1 302 Found Date: Mon, 04 Feb 2002 20:13:54 GMT Server: Apache/1.3.12 Cobalt (Unix) mod_jk mod_ssl/2.6.4 OpenSSL/0.9.5a PHP/4.0.3pl1 mod_auth_pam/1.0a FrontPage/4.0.4.3 mod_perl/1.24 Connection: close Content-Type: text/html; charset=iso-8859-1 adam
Re: modperl growth
Dave Rolsky [EMAIL PROTECTED] writes: On 4 Feb 2002, Dave Hodgkinson wrote: And if the Slashcode were as easy to install and customise as phpnuke... For OSCON (and hopefully YAPC too), I've submitted a talk on using Module::Build (an ExtUtils::MakeMaker replacement) for modules and using it to build an application installer. For slashcode, the HTML templating is a little hairy although beutifully crafted and using Template Toolkit. It's just real hard to find your way round the first time. I'm not sure how on-topic this is anymore, though I don't think creating a separate list would exactly help at this point. I'm sure several mod_perl advocacy lists have spun out like a little UFO in Conway's game of life and disappeared off the edge of the screen already... -- Dave Hodgkinson, Wizard for Hire http://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Interim Technical Director, Web Architecture Consultant for hire
[OT] RE: modperl growth
:: - Install Apache and mod_perl, or use an existing installation. :: :: - Install all the needed modules, template files, images, etc. [cut] Dave, I too try to automate installations as much as possible. Within Perl, I've found it possible to dispense with a separate configuration file for almost any application, even those with an RDBMS back-end. Under *nix it's really easy to automate things, under Win32 it's a little more difficult (file permissions are a bastard to manipulate). Perl can analyse its own environment very accurately, and once it has this awareness it's really easy to achieve automation. Anyone can do this, but most of us are too lazy for such niceties, which is too our detriment I think. However, all of my work in this direction requires that Perl and any required modules/libraries are already installed - I have never attempted to do an all-in-one install, although I do see this as being relatively easy to achieve. I would love to contribute to any efforts towards an out-of-the-box installer. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/
Re: mod_perl, OpenPGP Math::Pari
Hi there, On Tue, 5 Feb 2002, Jason Galea wrote: [snip] My only guess is that somehow mod_perl on the production server is using a different library [snip] Anyone? any clues on where to start looking? perl -V That's lower case perl, upper case V. 73, Ged.
modifying apache config at runtime
Is is possible to modify the in-memory apache configuration at runtime? I've seen modules that allow you to parse and modify the httpd.conf file, but that's not really what I'm looking for. In particular I want to set the value of ErrorDocument. Thanks, Peter Beardsley Appropriate Solutions, Inc. [EMAIL PROTECTED]
Re: modifying apache config at runtime
On Mon, Feb 04, 2002 at 04:47:27PM -0500, Peter Beardsley wrote: Is is possible to modify the in-memory apache configuration at runtime? I've seen modules that allow you to parse and modify the httpd.conf file, but that's not really what I'm looking for. In particular I want to set the value of ErrorDocument. If all you want to do is that you can just use the custom_response method. Here are a couple of examples... # on bad requests, redirect to some documentation $r-custom_response(BAD_REQUEST, http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html;); # but on unauthorized requests, send to a local file $r-custom_response(FORBIDDEN, /landlubber.html); You'll have to do this for every request, because you're cannot change the global config, only the child's localized configuration.. -- Paul Lindner[EMAIL PROTECTED] | | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
Re: Make test issue with the URI module
Thomas See below. Cheers Ron Savage [EMAIL PROTECTED] http://savage.net.au/index.html When I tried the make test from the mod_perl installation I had an error saying that the module URI couldn't be found. I then downloaded and installed the URI module from cpan.org: URI-1.18 and now I get the following error: /usr/bin/perl t/TEST 0 Can't locate object method new via package URI::URL at ../blib/lib/Apache/te st.pm line 252. I ran into the same problem yesterday. I 'solved' it by adding use URI::URL; to blib/lib/Apache/test.pm Does anyone know why this fails or how to fix it properly? If I recall, years ago the module was called URI::URL, and is now called URI. _If_ they are method-call compatible, you could change the source from use URI::URL; to use URI;
Re: weird problem. Lost of the POST data
I had similar problems not too long ago.
The reason i believe is - 'You can only read POST data from STDIN
_once_'.
Aka, in a mod_perl script if you do something like:
my $q1 = new CGI;
my $q2 = new CGI;
my $name1 = $q1-param(name);
my $name2 = $q2-param(name);
$name2 will not be set if the data was POST'ed. This is because the $q1
object would have already read in data from STDIN and its now no longer
available to any other objects (including $q2). If it was a 'GET'
request, you would have no such problem as GET request query strings are
in $ENV{'QUERY_STRING'} and you can read from that as many times as you
like.
The moral of the story being, for a single request never use more than
one CGI object (instantiate one and then pass it around)
cheers,
simran.
On Tue, 2002-02-05 at 03:31, Brett W. McCoy wrote:
On Mon, 4 Feb 2002, Oscar Serrano wrote:
some days ago I wrote to ask for this problem: The CGI.pm (sometimes) could
not receive the POST data. I tried all you recomended me here in the list.
But I still had the problem. Finally I decide to kick out CGI.pm and start
to use the old cgi-lib.pl. But I still had the same problem. Then I turnet
to Apache::Request, and since I use it, I've never had the same problem.
I just tell you because perphaps somebody may have the same problem. I
don't really understan if the problem is in mod_perl, in Apache, in Templat
Toolkit, in my ultrasecure patched kernel, in CGI.pm, but the point is that
Apache::Request seems not to loose any post data :-?
I had a similar problem a few days ago with a form processing engine I
developed with mod_perl Text::Template. It takes a sequence of states
out of a database and generates a 'wizard' to lead a user through a set of
forms for, say, an employment application, membership application, etc.
It uses a combination of CGI.pm for some of the high-level front end
stuff, and uses the Apache::* modules for the lower level stuff (cookies,
session management, etc). Anyway, I had this wierd bug that instead of
the straight sequence of forms, it would do the first form, then the
second, the the first again, then the third, then the first again, then
the fourth, and so on. POST data was either missing, or incomplete, or
was picking up values from several pages back.
I discovered what the problem was: I had a hash in one of my top-level
class files (the system is object-oriented) that was being used as a
global variable, a hash that had data that changed a lot. Bad juju with
mod_perl! Moving the hash into the class constructor and making sure it
got properly blessed into that class fixed the problem.
Another issue that can cause problems, especially using the OOP interface
to CGI.pm under mod_perl, is using a global CGI object and using it inside
of subroutines:
my $cgi = new CGI;
...
sendmail('A message');
...
sub send_mail {
my $msg = shift;
print $cgi-h1('Something');
print $cgi-p;
...
}
This will cause some wierd problems. The solution is to not use globals
inside your subroutine, but pass what you need into it:
sendmail($cgi, 'A Message');
sub send_mail {
my $q = shift;
my $msg = shift;
...
}
http://www.chapelperilous.net/
When the wind is great, bow before it;
when the wind is heavy, yield to it.
Re: Speed of downloading problem.
Scott See below. Cheers Ron Savage [EMAIL PROTECTED] http://savage.net.au/index.html Does anyone have any clues what to try? One thought here was to go to 2.0, but we don't know if that will screw up the mod-perl that is built for the Apache 1.3.20 and Ron Savages mod_perl binary. I'm clueless of course :-). But just for the record, I helped document this pre-built binary, but Randy Kobes deserves the credit. Start here: http://savage.net.au/Perl.html#Configuring-Apache
Re: modperl growth
My .05... I run a small communal webserver. Software had to be free, secure, stable, support Perl, multiple domains and ASP, be reasonably simple, originally run on Win32 and be capable of migration to Linux later. Nobrainer -- Apache, mod_perl, Apache::ASP. Only difficulty was getting mod_perl installed, it helped that I had a background in IT, I suspect a non-professional would find it impossible. Which is a shame because Win$ users expect everything to work out of the box wihout having to know anything. That's not meant as a criticism, but I think it's the reality now. regards, Rod === The sender has never accepted any funding from Enron. Any suggestion to that effect will be met with legal action.
Re: ld: 0711-319 WARNING: Exported symbol not defined:
Thanks Ged, But I didn't have any luck with the archives either. Maybe this is a dev level question? Cheers, JS. Hi there, On Thu, 31 Jan 2002, J S wrote: Apache compiles OK, but during make there are a lot of the following messages: .. .. ld: 0711-319 WARNING: Exported symbol not defined: Perl_yyrule ld: 0711-319 WARNING: Exported symbol not defined: cast_i32 [snip] .. .. and so on My environment is AIX 4.3.3.0 Didn't see a reply yet so I thought I'd throw in a suggestion. There have been several discussions in the not-too-distant past about compiling mod_perl under AIX. Never done it myself. Maybe you could check out one of the mod_perl List archives for AIX? 73, Ged. _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: Make test issue with the URI module
On Feb 04, 2002 at 16:24:38 +0100, Thomas Klausner wrote: Does anyone know why this fails or how to fix it properly? This question was originally asked back in August. http://mathforum.org/epigone/modperl/sehpholzhex With some followup... http://mathforum.org/epigone/modperl/zhenphimgrand --rick
Re: [OT] RE: modperl growth
Hello, JHI've found it possible to dispense with a separate configuration file JHfor almost any application, even those with an RDBMS back-end. Under JH*nix it's really easy to automate things, under Win32 it's a little more JHdifficult (file permissions are a bastard to manipulate). Perl can JHanalyse its own environment very accurately, and once it has this JHawareness it's really easy to achieve automation. So you are right about this, but let me add a caveat. Many times you need to cooperate with a third-party package management system. For example, an RPM database, or a stow or encap repository. In the latter case especially the paths that files are referenced at (typically /usr/local) differ from the places they actually live (typically a mounted repository). (I believe the Andrew File System has a similar problem, too.) Stuff using GNU autoconf is pretty easy to work into this by specifying a PREFIX at configure time. As of Perl 5.6.0 the Perl base install system accomodates for this as well, allowing you to specify different stuff to go into @INC versus where make install puts the package. Perl modules aren't as nice to fix. They automatically want to go where Perl is installed. If you want to rev packages separately, regular make install doesn't do the right thing. One last thing that is hard is where is your DocumentRoot? This is a huge problem for web applications being installable out of the box. Perl can't necessarily figure that out by itself, either. I guess my point is that installation is hard. Rather than trying to make it work for everybody out of the box, you should make it work for the typical case out of the box, and then provide hooks for installing it in custom places. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: modperl growth
On Sat, 2 Feb 2002, Robin Berjon wrote: http://www.securityspace.com/s_survey/data/man.200201/apachemods.html?mod=cGVybA== For some reason, in December, it would seem that modperl just jumped ahead in market share (from 13% to nearly 20%). [...] At least on Netcraft big jumps are usually explained by a big hosting provider or a domain name parking service changing servers. 13% to 20% does seem odd though. -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com
Re: [OT] RE: modperl growth
On Mon, 4 Feb 2002, Andrew Ho wrote: One last thing that is hard is where is your DocumentRoot? This is a huge problem for web applications being installable out of the box. Perl can't necessarily figure that out by itself, either. You take a guess and then ask the user to confirm. And you can't guess you just ask. There's nothing wrong with an interactive installer. What kills mod_perl apps is they simply have a README or INSTALL that says Copy all the template files to a directory called 'app-root' under your document root. I guess my point is that installation is hard. Rather than trying to make it work for everybody out of the box, you should make it work for the typical case out of the box, and then provide hooks for installing it in custom places. I think the best installer is an interactive installer that tries really hard to provide good defaults. -dave /*== www.urth.org we await the New Sun ==*/
