Re: Proposal for building knowledgebase website.

Hello all,

So what is the plan at this moment? Hoe is going to do what?

Regards,
Gevik.

> -----Original Message-----
> From: pgsql-www-owner(at)postgresql(dot)org [mailto:pgsql-www-
> owner(at)postgresql(dot)org] On Behalf Of Dave Page
> Sent: Friday, June 10, 2005 10:24 AM
> To: Magnus Hagander; josh(at)agliodbs(dot)com; Marc G. Fournier
> Cc: pgsql-www(at)postgresql(dot)org
> Subject: Re: [pgsql-www] Proposal for building knowledgebase website.
>
>
>
> > -----Original Message-----
> > From: Magnus Hagander [mailto:mha(at)sollentuna(dot)net]
> > Sent: 10 June 2005 09:02
> > To: josh(at)agliodbs(dot)com; Marc G. Fournier
> > Cc: Dave Page; pgsql-www(at)postgresql(dot)org
> > Subject: RE: [pgsql-www] Proposal for building knowledgebase website.
> >
> > 3) How does bric handle the logins? Right now there is one
> > login for the
> > /admin/ stuff, but it's not exactly flexible to maintain the passwords
> > there. And we need some kind of "unified login system" between the
> > different parts IMHO - so you don't need a separate account to
> > edit/submit doc comments from editing techdocs pages.
>
> I don't believe this is necessary, and am currently envisaging Bricolage
> as being an almost totally stand-alone system, integrated with the main
> site purely via CVS and a suitable script to add/remove/update files
> every few minutes or so.
>
> The downside of that is that there are 2 authoring interfaces, one for
> the main part of the site, and one for the PGDN or whatever it gets
> called. I do not think this is an issue though, as the whole point of
> using Bricolage is to allow people other than use to do the work. At
> worst it will mean that maybe 5 or 6 of us might use both interfaces.
>
> The upsides of such an architecture include:
>
> - Vastly simplified implementation.
> - No dependence on Bricolage. If it all goes belly-up, then we (the
> webmasters/sysadmins) only have to worry about fixing CVS->Webserver.
> Bric could be fixed in a more leisurely manner.
> - Changes/upgrades to Bric or organisational issues for the PGDN
> contributors needn't concern us in any way, as long as the same output
> is produced in the same place.
>
> > That said, personally I think people are vastly
> > overestimating the work
> > needed to just stick a WYSIWYG editor into the current
> > framework and be
> > done with it. I know I did one of these for work a couple of
> > weeks back,
> > and it took me *2 hours*. I looked into using it straight up for the
> > postgresql site, but I got stuck on the HTML validation stuff.
>
> Agreed.
>
> > And I also think peopel are vastly *underestimating* the work
> > needed to
> > get a "stock CMS" to "play nice" with what we already have.
>
> Not necessarily IMHO, if we take the approach I suggest above.
>
> Regards, Dave.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match