[theforum] Rebuild progress and this week's actions

[Seb Potter]

 > Nagrom spaketh thusly:
> therefore, i think 3 key requirements missing are:
> 
> 1. SPEED -- i don't know where or how userfrenzy is hosted
> (it could be at john's house which would explain), but the PoC is SLOW.
> did anyone else notice the old "8 second delay" went away
> when we dropped our DEDICATED linux/oracle setup for a
> SHARED win2k/MSSQL one? does anyone want that slug back?

Please don't confure Userfrenzy, which is John's personal server and 
runs about a bazillion sites with the new server, Tempest.

If you wanna see how responsive Drupal is on a P3/500 with 128MB RAM and 
a crappy old hard disk over ADSL, check out http://poked.org which is my 
site and was basically setup to see how Druapl runs on really shoddy 
hardware.

If you wanna see how Drupal runs when it's been setup on a reasonable 
server with a little care and attention, check out http://drupal.org 
which is reaonably close to the levels of traffic that evolt gets.

> 2. URL structure. the current system has a bizarre yet useful page address
> system. namely, the random section of the URL which can be
> made into anything.
> can we reproduce that with mod-rewrite? (i think Garrett is
> addressing it). we're not going to have to add a line to htaccess for every
> past and future article, are we? or every permutation that currently 
> exists?
> YUCK!

Well, this is pretty straightforward. If the article exists and we know 
the URL now, and we change that URL, as long as we know what the old URL 
was, we can keep it. Full stop, no argument. This shouldn't even need to 
be discussed. As everything is just data and code, this is the really, 
really easy bit.

Now, it's true that the URL scheme is going to change with a new site, 
but that doesn't preclude us from making them usable. I'm trying to find 
a good solution for this right at the moment, but pretty much it's the 
case that we can have Apache do some nice URL rewriting for us based on 
a lookup. We can do this pretty automatically and reasonably easily.

> 3. quality HTML. again, i'm unqualified as an undrupalized individual to
> participate, except to say, please view the current source.
> drupal left to its own devices makes some really horrible markup.
> i dare say dreamweaver/frontpage-horrible kind of markup.

Drupal doesn't do HTML. People do HTML. The HTML used in the templates 
is going to be as good as the person that writes it. :)


Basically, unless we outlay a large amount of cash money, there's no way 
we can keep with the existing site. Moving away from Jeff's server on 
our new, paid-for server is a priority. We can't stay with CF, so 
reimplementing has got to be the way to go.


There's a lot to, but we can do it. Let's get in on.

Seb.