Date: Fri, 6 Aug 1999 11:24:13 +0100 From: Nik Clayton <nik@freebsd.org> To: Jim Mock <jim@blues.ghis.net> Cc: advocacy@FreeBSD.org Subject: Re: followup: advocacy.freebsd.org (fwd) Message-ID: <19990806112413.A38499@kilt.nothing-going-on.org> In-Reply-To: <19990806121610.A13888@blues.ghis.net>; from Jim Mock on Fri, Aug 06, 1999 at 12:16:10PM %2B1000 References: <19990806121610.A13888@blues.ghis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Jim,
On Fri, Aug 06, 1999 at 12:16:10PM +1000, Jim Mock wrote:
> Rob's asked me to forward this on to the list. He seems to be having
> some trouble with getting mail through to certain places.
Could you forward this reply on to Rob as well, if he doesn't see it.
Thanks.
> 3. Nik brought up the issue of tools used by the advocacy project.
>
> Everything was done with the issues that Nik brought up in
> mind. The source of the advocacy site was written in SGML and
> converted to HTML through make.
That's not the issue, sorry if it was perceived that way.
My impression was that a lot of the content on the advocacy site will be
stored in a backend database (mySQL, Postgres, or similar -- the precise
DB doesn't matter much), and that some mechanism (CGI scripts, PHP?) will
be used to produce the dynamic HTML pages.
First, let me say that this is, by and large, a good idea. Where you have
content that can conceivably be viewed in several different ways ("Show me
all the articles about FreeBSD in the press sorted by date. Now show them
to me sorted by publication. Now show them to me categorised in to
whether or not they were 'good' or 'bad' articles.", and so on) is a good
idea, and can make site maintenance much easier.
However, I have my concerns:
1. This raises the bar for people who want to mirror the site. Now they
need to have a database installed (which may be an issue for some
people, depending on the resources they can offer), and we need a
stable mechanism to keep the mirrors up to date with the central
database.
Note that simply having the mirrors pull the content off the central
database is not, IMHO, acceptable. This removes most of the advantages
of mirroring the site, as we then have (a) a single point of failure
that can bring down all the mirrors, and (b) the page will still only
appear as fast as the connection between the mirror site and the
central database. This completely destroys the usefulness of the
mirrors.
2. Similarly to (1), this also raises the bar for anyone who wants to
contribute to the site.
Assume that the majority of FreeBSD contributors (and potential
contributors) do not have permanent access to the 'net. I'll use
myself as an example.
If I want to make and/or submit changes to the website at the moment
I can use CVSup to download the web pages, run "make" to generate the
HTML, and browse the whole site offline. With the exception of a
couple of CGI scripts, I don't even need to run a local webserver, as
my browser can be pointed at the files on the disk.
This makes it very easy to test out my changes before I submit them
and/or (in a committer's case) commit them.
I can't do this for the advocacy site if the majority of the content
is database driven. In order to be able to see and test my
contributions before I send them I'll need to (pretty much) run a
mirror of the advocacy site.
This is not impossible, particularly if all the software to do so is
in the ports collection. But it does make it that little bit more
difficult.
3. An important issue is that of 'change control'. With CVS we get
pretty much all the change control support we need (with the exception
of a few minor niggles).
If important parts of the advocacy site are stored in a database then
we should try and replicate that support within the database and/or
the table schema. This means support for logging;
Time and date of each change
The user who made the change
A 'revision number' for the information in that row
A 'commit log' for that row
and the ability to roll back changes as necessary (roll-back in CVS
terms, not database terms).
4. The other important issue is language and character set. We should
be making it possible for the various translation teams to translate
the advocacy site. For information that's stored in the database we
need to ensure that the database can support information in different
character sets. We also need to ensure that it's as easy as possible
for the translation teams to see what's changed in the content between
any two particular revisions.
I don't think any of these are insurmountable, but I do think it's important
to do them properly.
However, more tellingly, I can't think of a single web site that's database
driven that has solved all the above. About the only database driven site
that I'm aware of that is mirrored is freshmeat.net, and that skips some
of the above by (a) being in a single language, (b) the mirrors seem to
be mirroring static content that's generated on the server, rather than
including the full database.
Comments?
N
--
[intentional self-reference] can be easily accommodated using a blessed,
non-self-referential dummy head-node whose own object destructor severs
the links.
-- Tom Christiansen in <375143b5@cs.colorado.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990806112413.A38499>