Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Re: Integration Requirements
Date: Tue, 6 Dec 2005 21:26:22 +0100
Message-ID: <6BCB9D8A16AC4241919521715F4D8BCE92E8EF@algol.sollentuna.se>
Thread-Topic: [pgsql-www] Integration Requirements
Thread-Index: AcX6idaYn+SWes+mRICzVfRzwGiO+wAGMyCA
From: "Magnus Hagander" <mha@sollentuna.net>
To: "Josh Berkus" <josh@agliodbs.com>, <pgsql-www@postgresql.org>
Cc: "Dave Page" <dpage@vale-housing.co.uk>

> > - Moving data; originally we'd looked at exporting from the=20
> cms into=20
> > the filesystem, and having script that did a cvs add/remove/commit=20
> > over the entire tree, into the main web CVS. This is still=20
> preferrable=20
> > from an 'ease of rebuilding' point of view, but might be=20
> easier just=20
> > to rsync the content from the filesystem of the cms machine=20
> to wwwmaster.
>=20
> This isn't really practical for a KB or many other=20
> components, which need to be highly dynamic, not a bunch of=20
> static pages.

I agree that this isn't very practical - one of the reasons I didn't
like it in the first place. It has the one advantage that if this system
breaks, it doesn't brek the website. But designing for a system that's
expected to break doesn't seem like a very good idea.

Then again, "highly dynamic" does *not* necessarily mean you can't use a
set of static mirrors to do it. You just need to isolate parts of the
system, and put them in the right place. This is something that in my
experience most stock CMSes today to a bad job of, whereas custom ones
can do a better one.

(Heck, it's no big problem to serve a dynamic discussion site that
easily survives "the slashdot effect" off a single CPU 233MHz pentium
box with non-raid scsi disks. I've done it. You just have to accept
redifining "immidiate" as "1 minute". Not many sites require things to
be more dynamic htan that.)


//Magnus