In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Kurt D. Starsinic) wrote:
> On Mon, Aug 06, 2001 at 03:14:05PM -0400, Scott R. Godin wrote:
> > I'm in a situation where there are a small number of people looking to
> > migrate a large well-traveled website from their current host (which is
> > on NT and makes extensive use of .asp, and ms-sql), to a red-hat linux
> > box of their own making, running apache, php, and mysql. I'd already
> > coded up a number of enhancements to the original site within the past
> > year, only to hit the stumbling block of having the current host
> > unwilling to make the *slightest* effort at upgrading the perl
> > installation or modules on their sole unix box (they have 30 or so NT
> > boxes) . . . .
> >
> > I need some ammunition. what have you got that I can really *use* here?
>
> PHP is based on a model of a-file-is-a-page. It's easy to set up a
> moderately useful dynamic website using PHP due to its shallow learning
> and implementation curves, but when you're done, what you've got is a
> website with an enumerated set of states, each of which corresponds to a
> file.
>
> This is not how the world is (mostly).
Basically the site is a collection of reviews for around 4600 Unreal
Tournament Third-party level designs. It also has a BBS forum, for users
to register and post with, links to download said level designs, and a
few other things.
http://www.planetunreal.com/nalicity/
> Eventually, you're going to want a system where the number of different
> states becomes huge. You'll probably be able to pull this off using PHP if
> you've designed the site with a component mindset, but it will get very
> difficult, *and it will stop looking like PHP*.
This depends... Primarily I'll be using Perl to access the Maps database
and Authors database.
Currently the Maps database consists of:
Type ID DateAdded Title FileName Description Size Rating
OrigRating ReviewFile AuthorID AuthorName AuthorEmail
Although once I've cleaned it up, I plan to 'normalize' it into the
Authors db which is currently going unused -- we don't have an "author
registration system" in place yet, although it's planned for the site
overhaul due soon.
If you go to the above link, and look at the Maps list on the right hand
side, you'll see pretty much what I wish to duplicate via perl, and
improve upon using DBI and DBD::MySQL.
I've got a prototype running with a local CSV file I've downloaded with
the aid of a few other perl scripts, and a quick-and-dirty sql select
buried in some .asp in the site-admin section of the website. This is
driven currently via DBD::CSV so it's NOT as fast as it COULD be with a
direct MySQL connection, however it DOES use a few neat tricks to
prevent hitting the database multiple times just to glean the stats from
it.
http://216.155.0.50/~sgodin/cgi-scripts/ncrp/ncmapslistdbi.cgi
This is already done and finished, and a 'search' for it is already
written, but not yet folded in. (I'm using the search script I wrote for
my personal copy of the database on my own system at present, and
haven't touched the .cgi in about 9 months other than minor minor
tweaking.
I'm not unwilling to learn php, far from it.. I just would like to
leverage the code I've already created for this, and had hoped to place
on the original site but got stonewalled by the present hosting
site-admins who were basically too chickenshit to upgrade [the few Perl
modules I needed] to more stable and bug-free versions. *shrug*
If you'd like to see the code for ncmapslist.cgi, I'll be happy to post
a link to a copy of the file, embedded in some <pre> tags on an html
page.
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Abigail) wrote:
> > I need some ammunition. what have you got that I can really *use* here?
>
>
> Nothing really. There isn't any magic bullet that Perl can do and PHP
> cannot. In fact, there's a large set of languages that can all do the
> same; they might do it differently, but that's the only difference.
That's about what I figured, but I'm still hoping for a few tidbits. :)
> But why fight the fight? Why would you even contemplate moving a large,
> well-travelled site to a low budget machine of which you don't have
> much control? If it's really large and well travelled, doesn't it need
> something better?
well, A> it's not 'my' site, the actual owner of the site is moving it
*away* from a hosting organization that's moving in directions that take
more and more away from the community we've built over the years.
B> it isn't exactly a low-budget machine. The box is a VA Linux 1000 1U
Rack Server, with dual P-III 750's, two 36 GB SCSI drives, 512 MB RAM
(which will be augmented shortly), dual fast ethernet ports, CDROM,
etc., with four front-mounted fans sucking air in and back toward a
rear-pointing fifth fan. Value of this box is approximately $3700, but
he picked it up for a mere $1350 at their "fire-sale".
C> all the control necessary will be the site-owners, as it will be run
from a hosted location of his choice... just not at the location it's
currently hosted from.
> Or you and I have totally different ideas about "large and well-travelled"?
I don't think so. :-) I can't offhand tell you how many hits the primary
site gained under this guy's leadership on a daily basis, but I do
remember being quite surprised at the number.
...hence his desire to run it under Apache and from unix, instead of on
the NT site we have now, with significant downtime, HTTP/1.1 500 errors
almost daily, database errors where the maps list won't load, etc. That
and the fact that we're locked into .asp on the site it's at now, and
they are VERY sure they want to use php instead, which also basically
means a move to unix-based servers..
--
Scott R. Godin | e-mail : [EMAIL PROTECTED]
Laughing Dragon Services | web : http://www.webdragon.net/
