Languages and backends.

[Joakim Ziegler <joakim helixcode com>]

There was a discussion on gnome-hackers a while ago about what scripting
language/content generation backend we should use for www.gnome.org and the
other GNOME sites. This is a pretty important decision, and one we should try
to make as soon as possible, since a lot of other things hinge on it.

What we're currently using on the different GNOME sites is as follows:


www.gnome.org (cvsmodule gnomeweb-wml):

www.gnome.org uses mainly WML (website metalanguage) which is invoked by
Autoconf and Automake to generate the actual site content. This content
involves mostly static HTML, some PHP (even some PHP/FI, but mostly 3), and a
few SSI (.shtml) pages. There's also a Python script or two doing some
backend generation, and quite possibly some Perl.

I have to take most of the responsibility for this being such a mess. In
retrospect, I don't really believe using WML, and in particular not Auto*, is
a good idea for a website.


developer.gnome.org (cvsmodule web-devel-2):

developer.gnome.org uses a combination of make and some custom perl scripts
to generate the site content, which is, as far as I can see, all static HTML.
It has some special needs, since a lot of the content is actually generated
from SGML (using jade at maketime).


news.gnome.org (not in CVS?):

news.gnome.org uses an old version of Squishdot, which is a Slashdot clone
running on Zope (which basically means it's Python with some extra
weirdness). It tends to fall over a lot, but I'm told this is caused by it
being an old version of Squishdot/Zope, and isn't inherent in the system.


www.gtk.org (?):

Shawn, could you enlighten us as to what www.gtk.org uses to store and
generate its content?


Now, what we're looking at is to try to unify these sites as much as
possible, both design, generation and maintenance wise (with the possible
exception of www.gtk.org, I'm still a little unclear as to the level of
integration the GTK+ people want. Once again, it'd be good to get some more
info). The ideal situation would be to settle on one scripting/generation
language, one way to generate everything, etc., and have this one unified
model be simple for people to set up and develop for.

In reality, it's probably going to be somewhat more heterogenous, since needs
differ, and we will have to maintain at least some backwards compatibility in
some cases (Gnotices will probably have to remain on Zope no matter what we
choose for the others. Feel free to prove me wrong).


I have a couple of recommendations and opinions, just to start this off. I
think Auto* and WML should be dropped. People have problems making it work,
and problems adding new stuff to the makefiles properly, etc. The build
frequently breaks (because web developers usually aren't software developers
with Auto* experience) which again makes it hard for other people to push
their updates, etc. WML is, in my opinion, a hacked-together multipass mess
which offers little benefit as compared to on the fly generation of pages.

My first hunch is to use PHP for everything. This has a number of advantages;
PHP is very easy to integrate with HTML, it's fast (especially PHP4, which is
running on the new GNOME web server), a lot of people know it, and so on.
It's also fairly easy to integrate with other languages where necessary.

Of course, that leaves Gnotices, which is running on Zope now, and would be
hard to transition to PHP, I think. Some people have suggested going for Zope
for the entire site, which might be an interesting thought. I have to admit,
I don't know Zope well enough to have a good opinion on this, although what
I've seen of Zope looks a little complex. Python is a much nicer language
than PHP, though. I also have some concerns about the speed of Zope, the
larger installations I've seen tend to feel a bit sluggish. Opinions and
testimonials are very welcome.

-- 
Joakim Ziegler - Helix Code web monkey - joakim helixcode com - Radagast IRC
      FIX sysop - free software coder - FIDEL & Conglomerate developer
            http://www.avmaria.com/ - http://www.helixcode.com/