Re: Volunteer wanted for PostgreSQL Techdocs
От | Dave Page |
---|---|
Тема | Re: Volunteer wanted for PostgreSQL Techdocs |
Дата | |
Msg-id | E7F85A1B5FF8D44C8A1AF6885BC9A0E490E5D0@ratbert.vale-housing.co.uk обсуждение исходный текст |
Список | 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 по дате отправления: