Re: [OT] RE: modperl growth
On Tue, 5 Feb 2002, Dave Rolsky wrote: 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. That's a good strategy (assuming a missing if in there somewhere). It can be augmented with the tactic of check for a running apache, see where it gets its config file from, and parse the config file to get the initial guess. (Note that I wouldn't want this to be a final guess; I'm using mod_perl in a virtual host config; the main apache config doesn't use it, and has a completely unrelated docroot (/usr/local/apache/htdocs as opposed to /home/appname/public_html)) 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. My what? Which files are templates? I don't know this unix stuff; copy doesn't work right. I think we've all probably heard these words before... 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. I agree; while I frequently leave unimportant considerations alone (note my main docroot above), I tend to have very poor luck with the works with the typical case out of the box, and then provides hooks which change with every bloo^W^W^W^W^Wfor installing it in custom places. I won't go into speculations why. Ed
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: [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 ==*/