X-Original-To: pgsql-www-postgresql.org@localhost.postgresql.org Received: from localhost (neptune.hub.org [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 68C12D1B47D for ; Wed, 17 Dec 2003 13:33:25 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 22016-09 for ; Wed, 17 Dec 2003 09:32:56 -0400 (AST) Received: from lakemtao03.cox.net (lakemtao03.cox.net [68.1.17.242]) by svr1.postgresql.org (Postfix) with ESMTP id E0898D1B496 for ; Wed, 17 Dec 2003 09:32:52 -0400 (AST) Received: from [192.168.0.13] ([24.170.201.69]) by lakemtao03.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031217133256.VVGY2192.lakemtao03.cox.net@[192.168.0.13]>; Wed, 17 Dec 2003 08:32:56 -0500 From: Robert Treat To: josh@agliodbs.com, "Gavin M. Roy" , pgsql-www@postgresql.org Subject: Re: Hello and some questions Date: Wed, 17 Dec 2003 08:32:53 -0500 User-Agent: KMail/1.5 References: <3FDE28DA.5070902@ehpg.net> <200312151951.06917.xzilla@users.sourceforge.net> <200312161407.20475.josh@agliodbs.com> In-Reply-To: <200312161407.20475.josh@agliodbs.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200312170832.54102.xzilla@users.sourceforge.net> X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200312/110 X-Sequence-Number: 3170 On Tuesday 16 December 2003 17:07, Josh Berkus wrote: > Robert, > > > 3b) Move any remaining bits of techdocs into a new architecture (current > > is crufty php manually maintained) I personally think it should be > > openacs, but even homebrew php done correctly would be a major upgrade. > > The problem is that OpenACS is an architecture, it's *not* a content > manager. The problem is that everyone talks about what needs to be done but no one actually does anything... > Honestly, my first thought when Justin "handed over" techdocs to > me (not that I;ve done anything with it) was to contact the OpenACS folks > and see if there was a full-service CMS built on OpenACS. There's not. I'm no openacs expert, but there are multiple CMS packages available. Whether they meet your definition of "full featured" I couldn't say. > > Also, Bricolage's setup of generating static files from dynamic content > should work a lot better with our site setup. It would mean that the > majority of the Techdocs material could be mirrored just like the rest of > www. yep, thats a bonus, though given we don't serve developer, techdocs, or advocacy through the mirror system now, I wouldn't think that its a terribly high priority. A better feature would be openacs 5.x support for internationalization, which IIRC we won't be getting with bric. > > If I end up running Techdocs, or if Elein does (I've suggested it becuase > of the amount of energy she's put into General Bits) we're going to want a > real CMS so that we don't spend time debugging HMTL/PHP that could be > better spent managing authors and writing. This is too rich. As the guy who has actually been stymied on several attempts to move techdocs into the future, and the one who is actually updating the content now, please let me know when one of you two is ready to "start running things". You seem to think that there is some floodgate of authors writing articles with no way to get them on-line... I just don't think thats the case. Techdocs works better when the casual passer by can post responses and updates to articles on the fly, building upon others body of work. This is why the guides portion has done well, but the downside to using the wiki software is that you generally have no good way to publish content that you want to remain static. acs gives you both of these things, which is why i think it's worth investigating. But as I said before, even homebrew php done correctly would be a big improvment over the code we have now. Right now 1/2 the site is straight files, 1/2 is coming from a database that's laid out badly and theres little to no interface into the database other than a mismatched version of psql... but all of this is secondary to getting Andreas code finished up so we can begin unifying the various websites. Thats where we really need to concentrate because it is the roadblock to new development... Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL