Re: Localization Structure Model

[Joakim Ziegler <joakim helixcode com>]

[I'm going to assume you meant to send this to the list]

On Thu, Nov 16, 2000 at 08:40:24AM +0500, Ryan Muldoon wrote:
>> On Thu, Nov 16, 2000 at 05:57:32AM +0300, Cleber Rodrigues Rosa Junior wrote:

>>> This way we could have more or less real mirrors, and still achieving (some
>>> level of) localization with mininal effort. I don't know about the actual
>>> process of fiddling with this kind of data in the gnome website, but there
>>> could be a frontend to this. People like Ralph Muldoon might want to put
>>> something like this together.
 
>> This is one possible way of doing it, but I think it's a little
>> overcomplicated. There are several reasons for this, and I think they're
>> worth mentioning here, not as criticism of your idea, primarily, but as
>> general things to think about.
 
>> 1) Putting normal page content in SQL sucks for a number of reasons. It's
>>   slow, it doesn't have the revision control advantages of CVS, people have to
>>   have a local database set up to test even simple pages locally, etc.

> I agree that revision control would be great, but how can we use cvs without 
> dealing with the troubles you outlined earlier?

Oh, that's not inherent in using CVS, it's more a problem with all sorts of
indirect generation of pages. What we do at Helix Code, for instance, which
has turned out to work quite well, is to simply have the entire web site
structure in CVS, so that when you check out the website module, it's a fully
functioning tree from the document root and up.

We also do some nice things with CVS branch tags so you can load your changes
onto a test server (which runs one branch) and then tag as RELEASE and update
the main server afterwards.


>> In general, I'd like to avoid SQL as much as possible. On sites like
>> www.gnome.org, which get massive traffic, it's a hog. We should use as many
>> flat files as possible, and where we use SQL, we should use cache files for
>> the overview pages and other often used parts of the site.
 
> SQL can be a really nice solution to the problem.....it provides for easy content
> updates.  If you're really worried about SQL taking too many resources, we can
> just generate flat files from the database itself.  We can build in version 
> control into the database schema as well.  With a simple cron job and mirroring
> software we can keep all of the international sites in sync with the main
> database.  I am worried that using flat files will lead to a lot of duplicated
> information, and extremely slow searching.  But we can probably work around that
> issue with flat files if that is what is decided upon.

Searching shouldn't be done with an SQL database anyway, it's a horrible
waste of resources. It should be done with a text indexing and searching
system, such as ht://dig.

Duplicated information should be avoided by using PHP (or other scripting
language) templates that are invoked from the flat files, much like you'd use
scripting language templates around content you fetch from databases.

There's a tendency to overuse SQL in the web development community. I used to
do it myself, producing entire sites where all the content was in a database,
etc. But I've stopped. Flat files are simply easier to work with, a couple of
orders of magnitude faster (you should have seen what happened when I
actually hit the mySQL database directly on the front page of www.gnome.org
back in the day), and easier to grok. It's also a lot easier for someone who
wants to work with/edit the pages to just pull the data from CVS and do what
he needs, without having to have a local mysqld running.

-- 
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/