Re: Volunteer wanted for PostgreSQL Techdocs - Mailing list pgsql-www

From Dave Page
Subject Re: Volunteer wanted for PostgreSQL Techdocs
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E490E5D0@ratbert.vale-housing.co.uk
Whole thread Raw
List pgsql-www

> -----Original Message-----
> From: Gevik babakhani [mailto:gevik@xs4all.nl]
> Sent: 21 June 2005 09:11
> To: 'Magnus Hagander'; Dave Page; 'Rod Taylor';
> pgsql-www@postgresql.org
> Subject: RE: [pgsql-www] Volunteer wanted for PostgreSQL Techdocs
>
> Hi,
> Regarding static content:
> Assuming the content is being exported from bircolage to disk
> (static!)
> I do not see any other way than to scan the directory in
> order to build the
> xml tree.

All content on the site must be static, as that is all we serve on the
main frontend servers. There is a script which crawls the dynamic site
periodically and saves all the output to static files for replication to
the servers. With your tree it would simply crawl all links it found,
saving each page as it went. The only thing you must do is make sure
that the URLs you expose do not have GET values in them. For example,
you should use mod rewrite to allow you to present the user with:

http://www.postgresql.org/pgdn/tree/0/1/

Which is rewritten by apache /on the backend server/ to:

http://www.postgresql.org/system/pgdn/tree.php?lvl1=0&lvl2=1

The frontend server will then have a static file on it matching the
first URL. Have a look at
http://gborg.postgresql.org/project/pgweb/cvs/co.php/portal/.htaccess?r=
1.11 to see how we rewrite requests for normal pages and rss feeds etc.

> It is properly me, but I am not to found if exporting the
> files to disk.
> Don't you guys this it would be better to read the content
> directly from
> bircolage database?

No, because that then makes us reliant on Bricolage and a single
database (unless we start installing PG+Slony on each of the frontend
servers - which isn't likely to happen on at least 2 of them). We want
to keep the website itself completely independent of any CMS used for
techdocs/pgdn so that we have far fewer places for things to go wrong,
fewer dependencies, and redundancy/load balancing across all our
frontend server network. In the worst case scenario, we could continue
to serve and update content with no difference seen by users even if
Bricolage vanished and never returned!

Regards, Dave.

pgsql-www by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: Volunteer wanted for PostgreSQL Techdocs
Next
From: Rod Taylor
Date:
Subject: Re: Volunteer wanted for PostgreSQL Techdocs