Thread: Bricolage: Impressive

First, a brief introduction, since I started working off-list: I expressed
some interest in helping work with the web site some months ago to Josh
Berkus, and was directed to Dave, and possibly Robert.  I think an E-Mail got
lost somewhere, however, so I didn't get further involved at that point.

Last week, roughly around the same time as all the other new folks signed on
to this list, I sent a message to Robert, Dave, and Marc asking if I could
help, and was directed to try out Bricolage as a possible way of powering the
Techdocs site.

My background is in Linguistics, with a fair bit of work and credit in
evaluating web sites for usability.  I'm employed with the job title of
"Database Developer & Administrator", which involves maintaining our
PostgreSQL installation and writing most of the interface programs that are
used by the company's employees.  This is done using Apache + Perl + Mason,
and I'm very familiar with the last two in particular.

</end introduction>

I now have a working installation of Bricolage installed, and have a better
understanding of how it works.  In a word, it's impressive.  Unless our
requirements for multilingualism (see previous message) prevent us from using
it, I think it's a very good candidate for generating/unifying all of the
PostgreSQL sites.

It was designed for daily use by journalists, who are not interested in
learning any form of markup, and who in most cases are not *allowed* to do any
form of markup, since this is handled by the site.  They write their articles
using plain text, generally as a sequence of paragraphs, though it's possible
to intersperse other user-definable "elements" such as headings, quotes, etc.
For instance, we could have an element called "SQL Code" that would be used
for examples.  Josh Berkus' "Adventures in SQL" would then be a series of
"Paragraph" blocks interspersed with "SQL Code" blocks.

[This is not a complicated process, either.  By the look of it, I could easily
move one of Josh's articles into Bricolage in under five minutes, just using
copy and paste from my browser.]

Each type of contribution has a workflow associated with it.  By default, an
article would go through the Edit Desk, Review Desk, Legal Desk, and Publish
Desk.  The workflow is completely customizable, so we could remove the Legal
Desk, add a Translator's Desk, for example.  It contains a complete audit
trail, and you can easily revert to an older version, if necessary.

Once an article gets to the Publish Desk, it gets "burned" into HTML by going
through a Mason template (default) or an HTML::Template template (alternate).
This template provides all of the markup and site layout functions, and
results in a plain HTML file, which can be automatically sent to any number of
locations by a variety of means (FTP and File System are available by default;
there may be others, and a simple cron job could fill in the gaps).

The Bricolage server can be run from anywhere -- it need not (and arguably
should not) be at www.postgresql.org:80.  The result is that a web server need
only serve plain HTML files, for maximum efficiency and ease of installation
and maintenance.


Based on what I understand of Plone and Bricolage, and of what we want, it
looks like Bricolage is the far better candidate, at least once you get around
the barrier of getting it set up.  This is purely my opinion, however.

I'll keep working on it, and see if I can get a simulation of the current
TechDocs site going.

Steve Simms
Database Developer & Administrator
Medical Media Systems, Inc.

I'm also voted for Bricolade, because it's based on Mason, which I
personally have use a lot on many projects.
Multilingual support could be implemented on top of Mason, see
for example www.pgsql.ru

We use custom tag
<* ru=>'something in russian', en=>'the same in english' *>

If you need function call we have i18n(ru=>'...', en=>'....');

Of course, our approach doesn't limited by 2 languages.
We found it's much easier and maitainable for small evolving projects to
use that approach (inline), than gettext, because it's easy just edit
component. But, for stable project, gettext would be better.


    Oleg
On Sat, 17 Jan 2004, Steve Simms wrote:

> First, a brief introduction, since I started working off-list: I expressed
> some interest in helping work with the web site some months ago to Josh
> Berkus, and was directed to Dave, and possibly Robert.  I think an E-Mail got
> lost somewhere, however, so I didn't get further involved at that point.
>
> Last week, roughly around the same time as all the other new folks signed on
> to this list, I sent a message to Robert, Dave, and Marc asking if I could
> help, and was directed to try out Bricolage as a possible way of powering the
> Techdocs site.
>
> My background is in Linguistics, with a fair bit of work and credit in
> evaluating web sites for usability.  I'm employed with the job title of
> "Database Developer & Administrator", which involves maintaining our
> PostgreSQL installation and writing most of the interface programs that are
> used by the company's employees.  This is done using Apache + Perl + Mason,
> and I'm very familiar with the last two in particular.
>
> </end introduction>
>
> I now have a working installation of Bricolage installed, and have a better
> understanding of how it works.  In a word, it's impressive.  Unless our
> requirements for multilingualism (see previous message) prevent us from using
> it, I think it's a very good candidate for generating/unifying all of the
> PostgreSQL sites.
>
> It was designed for daily use by journalists, who are not interested in
> learning any form of markup, and who in most cases are not *allowed* to do any
> form of markup, since this is handled by the site.  They write their articles
> using plain text, generally as a sequence of paragraphs, though it's possible
> to intersperse other user-definable "elements" such as headings, quotes, etc.
> For instance, we could have an element called "SQL Code" that would be used
> for examples.  Josh Berkus' "Adventures in SQL" would then be a series of
> "Paragraph" blocks interspersed with "SQL Code" blocks.
>
> [This is not a complicated process, either.  By the look of it, I could easily
> move one of Josh's articles into Bricolage in under five minutes, just using
> copy and paste from my browser.]
>
> Each type of contribution has a workflow associated with it.  By default, an
> article would go through the Edit Desk, Review Desk, Legal Desk, and Publish
> Desk.  The workflow is completely customizable, so we could remove the Legal
> Desk, add a Translator's Desk, for example.  It contains a complete audit
> trail, and you can easily revert to an older version, if necessary.
>
> Once an article gets to the Publish Desk, it gets "burned" into HTML by going
> through a Mason template (default) or an HTML::Template template (alternate).
> This template provides all of the markup and site layout functions, and
> results in a plain HTML file, which can be automatically sent to any number of
> locations by a variety of means (FTP and File System are available by default;
> there may be others, and a simple cron job could fill in the gaps).
>
> The Bricolage server can be run from anywhere -- it need not (and arguably
> should not) be at www.postgresql.org:80.  The result is that a web server need
> only serve plain HTML files, for maximum efficiency and ease of installation
> and maintenance.
>
>
> Based on what I understand of Plone and Bricolage, and of what we want, it
> looks like Bricolage is the far better candidate, at least once you get around
> the barrier of getting it set up.  This is purely my opinion, however.
>
> I'll keep working on it, and see if I can get a simulation of the current
> TechDocs site going.
>
> Steve Simms
> Database Developer & Administrator
> Medical Media Systems, Inc.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org
>

    Regards,
        Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

'k, we have one vote from someone that has only started to play with it
... and one vote from someone who has used the base technology ...

do we have anyone that is against using this?  Steve seems to indicate
that this could be used for not just techdocs, but for the other sites as
well ... do we want to look at this too, since Oleg seems to indicate the
whole internationalization stuff shouldn't be an issue using it?

Steve, is this something that, if I install it on the root server,
everything is maintained through web interfaces, or is there shell access
required for maintaining?

On Sat, 17 Jan 2004, Oleg Bartunov wrote:

> I'm also voted for Bricolade, because it's based on Mason, which I
> personally have use a lot on many projects.
> Multilingual support could be implemented on top of Mason, see
> for example www.pgsql.ru
>
> We use custom tag
> <* ru=>'something in russian', en=>'the same in english' *>
>
> If you need function call we have i18n(ru=>'...', en=>'....');
>
> Of course, our approach doesn't limited by 2 languages.
> We found it's much easier and maitainable for small evolving projects to
> use that approach (inline), than gettext, because it's easy just edit
> component. But, for stable project, gettext would be better.
>
>
>     Oleg
> On Sat, 17 Jan 2004, Steve Simms wrote:
>
> > First, a brief introduction, since I started working off-list: I expressed
> > some interest in helping work with the web site some months ago to Josh
> > Berkus, and was directed to Dave, and possibly Robert.  I think an E-Mail got
> > lost somewhere, however, so I didn't get further involved at that point.
> >
> > Last week, roughly around the same time as all the other new folks signed on
> > to this list, I sent a message to Robert, Dave, and Marc asking if I could
> > help, and was directed to try out Bricolage as a possible way of powering the
> > Techdocs site.
> >
> > My background is in Linguistics, with a fair bit of work and credit in
> > evaluating web sites for usability.  I'm employed with the job title of
> > "Database Developer & Administrator", which involves maintaining our
> > PostgreSQL installation and writing most of the interface programs that are
> > used by the company's employees.  This is done using Apache + Perl + Mason,
> > and I'm very familiar with the last two in particular.
> >
> > </end introduction>
> >
> > I now have a working installation of Bricolage installed, and have a better
> > understanding of how it works.  In a word, it's impressive.  Unless our
> > requirements for multilingualism (see previous message) prevent us from using
> > it, I think it's a very good candidate for generating/unifying all of the
> > PostgreSQL sites.
> >
> > It was designed for daily use by journalists, who are not interested in
> > learning any form of markup, and who in most cases are not *allowed* to do any
> > form of markup, since this is handled by the site.  They write their articles
> > using plain text, generally as a sequence of paragraphs, though it's possible
> > to intersperse other user-definable "elements" such as headings, quotes, etc.
> > For instance, we could have an element called "SQL Code" that would be used
> > for examples.  Josh Berkus' "Adventures in SQL" would then be a series of
> > "Paragraph" blocks interspersed with "SQL Code" blocks.
> >
> > [This is not a complicated process, either.  By the look of it, I could easily
> > move one of Josh's articles into Bricolage in under five minutes, just using
> > copy and paste from my browser.]
> >
> > Each type of contribution has a workflow associated with it.  By default, an
> > article would go through the Edit Desk, Review Desk, Legal Desk, and Publish
> > Desk.  The workflow is completely customizable, so we could remove the Legal
> > Desk, add a Translator's Desk, for example.  It contains a complete audit
> > trail, and you can easily revert to an older version, if necessary.
> >
> > Once an article gets to the Publish Desk, it gets "burned" into HTML by going
> > through a Mason template (default) or an HTML::Template template (alternate).
> > This template provides all of the markup and site layout functions, and
> > results in a plain HTML file, which can be automatically sent to any number of
> > locations by a variety of means (FTP and File System are available by default;
> > there may be others, and a simple cron job could fill in the gaps).
> >
> > The Bricolage server can be run from anywhere -- it need not (and arguably
> > should not) be at www.postgresql.org:80.  The result is that a web server need
> > only serve plain HTML files, for maximum efficiency and ease of installation
> > and maintenance.
> >
> >
> > Based on what I understand of Plone and Bricolage, and of what we want, it
> > looks like Bricolage is the far better candidate, at least once you get around
> > the barrier of getting it set up.  This is purely my opinion, however.
> >
> > I'll keep working on it, and see if I can get a simulation of the current
> > TechDocs site going.
> >
> > Steve Simms
> > Database Developer & Administrator
> > Medical Media Systems, Inc.
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> >                http://archives.postgresql.org
> >
>
>     Regards,
>         Oleg
> _____________________________________________________________
> Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> Sternberg Astronomical Institute, Moscow University (Russia)
> Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
> phone: +007(095)939-16-83, +007(095)939-23-83
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly
>

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Marc G. Fournier wrote:
> do we have anyone that is against using this?  Steve seems to
> indicate that this could be used for not just techdocs, but for the
> other sites as well ... do we want to look at this too, since Oleg
> seems to indicate the whole internationalization stuff shouldn't be
> an issue using it?

I read that he indicated that internationalization *is* an issue if you
have lots of languages and frequent, irregular updates.  To me, keeping
the translations inline seems OK for a couple of languages and small
sites, but for what we're talking about here it seems shortsighted.

Marc G. Fournier said:
> do we have anyone that is against using this?  Steve seems to indicate
> that this could be used for not just techdocs, but for the other sites as
> well ... do we want to look at this too, since Oleg seems to indicate the
> whole internationalization stuff shouldn't be an issue using it?

For my part, I'm not sure how well internationalization will work.  I tried
searching through the Bricolage mailing list archives, but SourceForge seems
to be acting up, and returns "no results" for any set of keywords.  I'll try
again later.

I think it will depend on what kind of internationalization we decide we need.
 Bricolage *is* being used for highly multilingual sites based on what I've
seen, though I'm not sure yet how they do it.

> Steve, is this something that, if I install it on the root server,
> everything is maintained through web interfaces, or is there shell access
> required for maintaining?

For normal purposes and most administration, yes.  I'm not yet sure about
things like adding/updating CSS files -- I'll let you know when I find out.
Other layout can definitely be done entirely through the web interface, so I
think it's safe to say that 90%+ of site administration can be done through
the web.

Steve Simms
Database Developer & Administrator
Medical Media Systems, Inc.

David, can you add some input into this?  The thread starts:

http://archives.postgresql.org/pgsql-www/2004-01/msg00188.php

On Sat, 17 Jan 2004, Peter Eisentraut wrote:

> Marc G. Fournier wrote:
> > do we have anyone that is against using this?  Steve seems to
> > indicate that this could be used for not just techdocs, but for the
> > other sites as well ... do we want to look at this too, since Oleg
> > seems to indicate the whole internationalization stuff shouldn't be
> > an issue using it?
>
> I read that he indicated that internationalization *is* an issue if you
> have lots of languages and frequent, irregular updates.  To me, keeping
> the translations inline seems OK for a couple of languages and small
> sites, but for what we're talking about here it seems shortsighted.
>
>

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

On Sat, 17 Jan 2004, Peter Eisentraut wrote:

> Marc G. Fournier wrote:
> > do we have anyone that is against using this?  Steve seems to
> > indicate that this could be used for not just techdocs, but for the
> > other sites as well ... do we want to look at this too, since Oleg
> > seems to indicate the whole internationalization stuff shouldn't be
> > an issue using it?
>
> I read that he indicated that internationalization *is* an issue if you
> have lots of languages and frequent, irregular updates.  To me, keeping
> the translations inline seems OK for a couple of languages and small
> sites, but for what we're talking about here it seems shortsighted.
>

You're right. The more I'm thinking about .postgresq.org sites, the more I
inclined to regular approach with Locale::Maketext::Lexicon.
http://www.autrijus.org/webl10n/webl10n.html - nice paper


    Regards,
        Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

On Saturday 17 January 2004 13:29, Steve Simms wrote:
> I now have a working installation of Bricolage installed, and have a better
> understanding of how it works.  In a word, it's impressive.  Unless our
> requirements for multilingualism (see previous message) prevent us from
> using it, I think it's a very good candidate for generating/unifying all of
> the PostgreSQL sites.
>

Initially there isn't a requirement that techdocs and the main website use the
same backend, as long as they can be given some type of unified look/feel
with the main site.  AFAICR no one has ever clamored to translate the
articles up on the techdocs website (though we're certainly not opposed to
it, just no one has really wanted to)   So multilingualism shouldn't be a
stumbling block for techdocs. One thing that we do need is the ablility for
users comments on articles, is there any provision for that?  Another thing
that could come up would be user articles submitted in pdf form (I just added
one yesterday),  is there a provision for that?

>
> Based on what I understand of Plone and Bricolage, and of what we want, it
> looks like Bricolage is the far better candidate, at least once you get
> around the barrier of getting it set up.  This is purely my opinion,
> however.
>
> I'll keep working on it, and see if I can get a simulation of the current
> TechDocs site going.
>

OK, if you can send us (or me at least) a url I'd be interested in browsing
around and adding an article or two.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

David, could you comment to Robert's questions below?

On Sun, 18 Jan 2004, Robert Treat wrote:

> stumbling block for techdocs. One thing that we do need is the ablility
> for users comments on articles, is there any provision for that?
> Another thing that could come up would be user articles submitted in pdf
> form (I just added one yesterday), is there a provision for that?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

On Jan 17, 2004, at 9:47 PM, Marc G. Fournier wrote:

> David, can you add some input into this?  The thread starts:
>
> http://archives.postgresql.org/pgsql-www/2004-01/msg00188.php

Ah, a new list and a new world. Thank you for alerting me to this, Marc.

I agree that Bricolage would be an excellent solution for TechDocs and
other Pg sites; Steve's comments are right on target. I also agree that
I18N can be tricky. Here's the deal.

The World Health Organization uses Bricolage to manage its Web site,
www.who.int. The WHO mandates that all of its content be published in
five languages: English, Spanish, French, Chinese, and one other I
can't remember right now (Russian?). Currently, the Web site is
published in English, French, and Spanish only; the other languages
will be added later. Here's how they do it.

You'll recall that Steve said that you can define fields for Bricolage
document types, such as "Paragraph", "Header", or "Code". What WHO does
is have three versions of each of these (well, not Code): "English
Paragraph", "English Header", "Spanish Paragraph", "Spanish Header",
"French Paragraph", and "French Header". The documents are originally
authored in one language, say French, and then translators translate
them by adding the appropriate fields. The result is something like
this:

=en_paragrah

Hello.

=es_paragraph

Hola.

=fr_paragraph

Bon jour.

And yes, there is an editing interface that uses this
approach--POD-like tags to indicate fields--which makes editing much
easier than using discreet textarea fields. The downside to this
approach, however, is that the documents can get rather unwieldy.
Ordering can also be tricky. And of course, the templates have to know
what they're outputting and where.

An alternate solution is to clone a document. This creates a completely
separate document that can then be translated. So if  document was
originally written in French, a translator would clone it, and then
convert the cloned version's contents into Spanish. A separate clone
would be used for English. This approach makes the documents much more
wieldy, and the templates don't have to be as intelligent. The
disadvantage of course is that the translations are actually
independent documents. This may be okay in some environments, but
others might prefer that they all stick together. This might be because
someone makes a change to the French original, and then wants to send
it to the Translation desk to ensure that the English and Spanish
translations are likewise updated. OTOH, one might just send it to the
Translation desk, and then it's up to the translator to find the right
clones and update them.

Anyway, these issues are a big raison d'être for Bricolage 2.0, which
is currently in the early stages of development. You can read about the
design docs here:

   http://www.bricolage.cc/docs/design/ElementRevision.html

One of the major new features of Bricolage 2.0 is "Input Channels".
Input channels allow a single document to have different channels for
input for its content. So, for example, a document might have
"English", "Spanish", and "French" input channels--or more, as many as
you define. Then, when a user checks out a document, she can just
switch channels to see the different input for those channels. This
keeps all of the translations together in a single document, but is far
more wieldy than the solution currently used at WHO.

Unfortunately, Bricolage 2.0 is probably a good 9-12 months away. Folks
who wish to help with the development would be most welcome! Just
subscribe to the bricolage-devel mail list and ask how you can help.

   http://sourceforge.net/mail/?group_id=34789

In the meantime, the approaches I mentioned above may get you where you
need to go. For better or for worse, I don't think there are good
multi-language document solutions in any CMS. I suspect that Bricolage
2.0 will be first in its class in this respect, all others having
solutions similar to the workarounds we use for Bricolage 1.x.

HTH,

David

--
David Wheeler                                     AIM: dwTheory
david@kineticode.com                              ICQ: 15726394
http://www.kineticode.com/                     Yahoo!: dew7e
                                                Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]

Guys,

As you know, I've always favored Bricolage for Techdocs.   It covers what I
want for acquiring writers who are not HTML-jockeys (like me), and is
immensely scalable, and I am already lightly involved in the Bric community
so I feel more able to troubleshoot issues.

However, there is a labor-intensive "templating" process in the initial Bric
set-up, which requires a good knowledge of HTML and Bric and a light
knowledge of Perl and Mason.   Elein was going to set this up initially but
became tied up in her start-up and hasn't had time.  I don't feel skilled
enough to do the templating.

If Steve is up to templating, I will happily work on porting articles.  In
addition to Steve's server, David Fetter set up a Bric server for
development, which may be still connected to the internet.

Robert: since what Bric does is build HTML pages, it is entirely possible to
"plug in" PHP applications as blocks of HTML text.   Comments could be
supported this way, as well as a Wiki (which I also believe we should have).

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

Guys,

Oh, and the other reason to use Bric is political; Bric is one of PostgreSQL's
few "killer apps" that really give companies a compelling reason to use
PostgreSQL if they are not already database-saavy.  Us using it would benefit
both projects.

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

I'm still following lightly all of these threads and am
still very interested in setting up templates
in Bricolage for techdocs.

Collaboration with someone else might ease
my time commitment pain, though.

Steve?

elein

PS: I cannot run bricolage on my own server until I
get upgraded to debian from old suse :-(

On Sun, Jan 18, 2004 at 05:35:49PM -0800, Josh Berkus wrote:
> Guys,
>
> As you know, I've always favored Bricolage for Techdocs.   It covers what I
> want for acquiring writers who are not HTML-jockeys (like me), and is
> immensely scalable, and I am already lightly involved in the Bric community
> so I feel more able to troubleshoot issues.
>
> However, there is a labor-intensive "templating" process in the initial Bric
> set-up, which requires a good knowledge of HTML and Bric and a light
> knowledge of Perl and Mason.   Elein was going to set this up initially but
> became tied up in her start-up and hasn't had time.  I don't feel skilled
> enough to do the templating.
>
> If Steve is up to templating, I will happily work on porting articles.  In
> addition to Steve's server, David Fetter set up a Bric server for
> development, which may be still connected to the internet.
>
> Robert: since what Bric does is build HTML pages, it is entirely possible to
> "plug in" PHP applications as blocks of HTML text.   Comments could be
> supported this way, as well as a Wiki (which I also believe we should have).
>
> --
> -Josh Berkus
>  Aglio Database Solutions
>  San Francisco
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org

Josh Berkus <josh@agliodbs.com> writes:
> Oh, and the other reason to use Bric is political; Bric is one of
> PostgreSQL's few "killer apps" that really give companies a compelling
> reason to use PostgreSQL if they are not already database-saavy.  Us
> using it would benefit both projects.

Indeed.  It looks like you already caught David Wheeler's attention;
perhaps he'd be willing to lend a hand, or at least superintend.

            regards, tom lane

> -----Original Message-----
> From: elein [mailto:elein@varlena.com]
> Sent: 19 January 2004 03:01
> To: Josh Berkus
> Cc: Robert Treat; Steve Simms; PostgreSQL Web Development Mailing List
> Subject: Re: [pgsql-www] Bricolage: Impressive
>
>
> as well as a Wiki (which I also believe
> we should have).

I'm fascinated by the current trend towards Wikis - what do they achieve
that user comments don't other than potentially allowing a malicious
user to cause havoc and potentially open the site to all sorts of legal
problems should something libelous be posted - something I kindof
expected you .usians to be particularly wary of?

With a system like Bricolage in place, surely we can allow enough
trusted people to be editors/publishers that we needn't allow any old
Tom, Dick or Harry (no offense Tom :-) ) to edit whatever they see fit,
but merely to add comments instead?

Regards, Dave.

David,

what I'd like to see is a built in search facility, so once document
has approved for publication, it could be searchable. It's nice feature
and we use it in our CMS (also, Mason based) and PostgreSQL has
contrib/tsearch2 (I'm one of the authors) and OpenFTS as a middleware,
so I don't see any problem to add search to Bricolade.

This will solve .postgresql.org problem with search engine if -www
will decide to go with Bricolade.

    Oleg
On Sun, 18 Jan 2004, David Wheeler wrote:

> On Jan 17, 2004, at 9:47 PM, Marc G. Fournier wrote:
>
> > David, can you add some input into this?  The thread starts:
> >
> > http://archives.postgresql.org/pgsql-www/2004-01/msg00188.php
>
> Ah, a new list and a new world. Thank you for alerting me to this, Marc.
>
> I agree that Bricolage would be an excellent solution for TechDocs and
> other Pg sites; Steve's comments are right on target. I also agree that
> I18N can be tricky. Here's the deal.
>
> The World Health Organization uses Bricolage to manage its Web site,
> www.who.int. The WHO mandates that all of its content be published in
> five languages: English, Spanish, French, Chinese, and one other I
> can't remember right now (Russian?). Currently, the Web site is
> published in English, French, and Spanish only; the other languages
> will be added later. Here's how they do it.
>
> You'll recall that Steve said that you can define fields for Bricolage
> document types, such as "Paragraph", "Header", or "Code". What WHO does
> is have three versions of each of these (well, not Code): "English
> Paragraph", "English Header", "Spanish Paragraph", "Spanish Header",
> "French Paragraph", and "French Header". The documents are originally
> authored in one language, say French, and then translators translate
> them by adding the appropriate fields. The result is something like
> this:
>
> =en_paragrah
>
> Hello.
>
> =es_paragraph
>
> Hola.
>
> =fr_paragraph
>
> Bon jour.
>
> And yes, there is an editing interface that uses this
> approach--POD-like tags to indicate fields--which makes editing much
> easier than using discreet textarea fields. The downside to this
> approach, however, is that the documents can get rather unwieldy.
> Ordering can also be tricky. And of course, the templates have to know
> what they're outputting and where.
>
> An alternate solution is to clone a document. This creates a completely
> separate document that can then be translated. So if  document was
> originally written in French, a translator would clone it, and then
> convert the cloned version's contents into Spanish. A separate clone
> would be used for English. This approach makes the documents much more
> wieldy, and the templates don't have to be as intelligent. The
> disadvantage of course is that the translations are actually
> independent documents. This may be okay in some environments, but
> others might prefer that they all stick together. This might be because
> someone makes a change to the French original, and then wants to send
> it to the Translation desk to ensure that the English and Spanish
> translations are likewise updated. OTOH, one might just send it to the
> Translation desk, and then it's up to the translator to find the right
> clones and update them.
>
> Anyway, these issues are a big raison d'Йtre for Bricolage 2.0, which
> is currently in the early stages of development. You can read about the
> design docs here:
>
>    http://www.bricolage.cc/docs/design/ElementRevision.html
>
> One of the major new features of Bricolage 2.0 is "Input Channels".
> Input channels allow a single document to have different channels for
> input for its content. So, for example, a document might have
> "English", "Spanish", and "French" input channels--or more, as many as
> you define. Then, when a user checks out a document, she can just
> switch channels to see the different input for those channels. This
> keeps all of the translations together in a single document, but is far
> more wieldy than the solution currently used at WHO.
>
> Unfortunately, Bricolage 2.0 is probably a good 9-12 months away. Folks
> who wish to help with the development would be most welcome! Just
> subscribe to the bricolage-devel mail list and ask how you can help.
>
>    http://sourceforge.net/mail/?group_id=34789
>
> In the meantime, the approaches I mentioned above may get you where you
> need to go. For better or for worse, I don't think there are good
> multi-language document solutions in any CMS. I suspect that Bricolage
> 2.0 will be first in its class in this respect, all others having
> solutions similar to the workarounds we use for Bricolage 1.x.
>
> HTH,
>
> David
>
>

    Regards,
        Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

> -----Original Message-----
> From: Oleg Bartunov [mailto:oleg@sai.msu.su]
> Sent: 19 January 2004 11:55
> To: David Wheeler
> Cc: Marc G. Fournier; Steve Simms; Peter Eisentraut;
> PostgreSQL Web Development Mailing List
> Subject: Re: [pgsql-www] Bricolage: Impressive
>
>
> This will solve .postgresql.org problem with search engine if
> -www will decide to go with Bricolade.

Umm, how? The current problem is that mnogosearch cannot cope with
300,000 plus pages, even in cache mode (a problem I'm actively working
on right now). Are you suggesting that all the archives get published
via Bricolage as well?

Regards, Dave.

On Mon, 19 Jan 2004, Dave Page wrote:

>
>
> > -----Original Message-----
> > From: Oleg Bartunov [mailto:oleg@sai.msu.su]
> > Sent: 19 January 2004 11:55
> > To: David Wheeler
> > Cc: Marc G. Fournier; Steve Simms; Peter Eisentraut;
> > PostgreSQL Web Development Mailing List
> > Subject: Re: [pgsql-www] Bricolage: Impressive
> >
> >
> > This will solve .postgresql.org problem with search engine if
> > -www will decide to go with Bricolade.
>
> Umm, how? The current problem is that mnogosearch cannot cope with
> 300,000 plus pages, even in cache mode (a problem I'm actively working
> on right now). Are you suggesting that all the archives get published
> via Bricolage as well?

Not, of course :) I suggest to separate different things -
official information, which comes through editorial board and archives.
I meant Bricolade with built in search to use for former type of sites.

Mnogosearch + PostgreSQL is not the best combination and it has no
proximity ranking, so releavation of search results are bad. Reindexing
require rebuilding indices, so, in my opinion you waste your time.
It has no future. Also, crawling archives is also waste of time and
resources. Let's see, if you have access to local files, why do you need
crawling ? From my experience crawling archives.postgresql.org takes a lot
of time just because of  each page generates up to 3 seconds !
Also, when your crawl archives you crawl web page, which contains a lot
of web thingies (navigation, advertisement,....). Do you need that ?
It's much better to index just postings. On fts.postgresql.org we had
light version of our CMS, we optimize for automated processing of postings,
so we could apply specialized parser and obtain metadata. That's what we'll
use on www.pgsql.ru for mailing list archives. It was planned to be released
really soon, but delayed because of some urgent works. And this archive
will be based fully on PostgreSQL, in very natural way :)

    Oleg

>
> Regards, Dave.
>

    Regards,
        Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

Dave,

> I'm fascinated by the current trend towards Wikis - what do they achieve
> that user comments don't other than potentially allowing a malicious
> user to cause havoc and potentially open the site to all sorts of legal
> problems should something libelous be posted - something I kindof
> expected you .usians to be particularly wary of?

Paranoia doesn't pay.  Really.   Despite Wiki's potential for abuse, the Wikis
out there have been remarkably grafitti-free.  For example, I don't know that
Wikipedia.org has been defaced once in the last season despite its public
profile, and more technical wikis like the madwifi wiki (http://
madwifiwiki.thewebhost.de/wiki/FrontPage) have gone their whole lifetimes
free of interference.    So that's *not* a consideration -- especially as any
good wiki includes version rollback.

What is a consideration is:
Pro-Wiki:
1) Provides an easy way for new users to contribute toward HOWTOs, etc.,
without requiring them to wait for passwords, authorization, and reading
extensive instructions.  This immediacy increases the likelyhood that someone
will contribute what they've learned.*
2) Offers a childishly easy editing system, also supporting the above
immediacy.
3) allows site administrators to move away from using e-mail to manage site
submissions from new authors ("Just put it up on the Wiki and I'll review it
later")

Anti-Wiki:
1) Content has to be dynamically rebuilt with each submission, making
mirroring difficult to impossible, especially as few Wikis have a "preview"
screen.
2) Tend to contribute to byzantine site structures that require an admin to
straighten out and re-link.
3) Formatting, graphical elements, and linking are severly limited by security
constraints, forcing most "articles" into formatted-text-only.
4) Difficult to search or TOC effectively.
5) Few, if any, Wikis allow setting permissions on pages which need
constrained editing rights.

Given these considerations, I feel that it would be a good thing to have a
wiki as a *corner* of the PostgreSQL.org and Techdocs Sites, but not as the
whole thing.  The GUI page (http://techdocs.postgresql.org/guides/GUITools)
has been a success for the existing Techdocs Wiki, except that nobody can
find it on their own.

(*Seriously.   I spent a portion of last week troubleshooting the madwifi
drivers for the IBM a/b/g wireless card; since madwifi had a wiki, I wrote up
my experiences *immediately* and they are now on the web for others to learn
from.  If I'd had to wait for a user_id and password and read 3 pages of
instructions on how to submit -- or gods forbid use CVS -- I would have
procrastinated indefinitely on posting)

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

On Mon, 19 Jan 2004, Dave Page wrote:

>
>
> > -----Original Message-----
> > From: Oleg Bartunov [mailto:oleg@sai.msu.su]
> > Sent: 19 January 2004 11:55
> > To: David Wheeler
> > Cc: Marc G. Fournier; Steve Simms; Peter Eisentraut;
> > PostgreSQL Web Development Mailing List
> > Subject: Re: [pgsql-www] Bricolage: Impressive
> >
> >
> > This will solve .postgresql.org problem with search engine if
> > -www will decide to go with Bricolade.
>
> Umm, how? The current problem is that mnogosearch cannot cope with
> 300,000 plus pages, even in cache mode (a problem I'm actively working
> on right now). Are you suggesting that all the archives get published
> via Bricolage as well?

Actually, for archives, I'm going to try and get the Crawler Oleg released
last week working, and I'm also going to look at his suggestion about
reducing the amount of information per message (clean out a bunch of
redundant information) ...

My projects for this week :)

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

> -----Original Message-----
> From: Josh Berkus [mailto:josh@agliodbs.com]
> Sent: 19 January 2004 17:41
> To: Dave Page
> Cc: PostgreSQL Web Development Mailing List
> Subject: Re: [pgsql-www] Bricolage: Impressive
>

Hi Josh,

> Paranoia doesn't pay.  Really.

It pays my wages actually! Seriously, as an IT manager I have to
consider every aspect of our systems at work and any potential risks to
the business from them. Our auditors would not even let any random
member of staff edit things on our public website, never mind Joe
Public, in case they opened us to prosecution somehow. We *have* to make
every best effort to ensure that none of the systems we deploy can cause
grief to the company.

I realise the PostgreSQL project is not the same as Vale Housing, but
still, the same considerations must be made to some extent.

> Despite Wiki's potential for
> abuse, the Wikis
> out there have been remarkably grafitti-free.  For example, I
> don't know that Wikipedia.org has been defaced once in the
> last season despite its public profile, and more technical
> wikis like the madwifi wiki (http://
> madwifiwiki.thewebhost.de/wiki/FrontPage) have gone their
> whole lifetimes
> free of interference.    So that's *not* a consideration --
> especially as any
> good wiki includes version rollback.

LOL!! So because it hasn't happened yet, it never will (or won't to us)?
Besides, a quick Google shows that Wiki defacements are hardly unheard
of, even if they can be rolled back.

<snip pros/cons>

Reading your pros and cons, the only *real* advantage of a Wiki over
some other CMS is that the would be editor/author needn't register to
use the system first. Given that registering for such a site and waiting
for a return email is likely to be more or less instant, and only
required upon the first use, I would rather use just one system for the
whole site, and know that we do at least have a valid email address for
each editor on the system (who would have had to agree to T&Cs upon
registration).

The advantages to such a system are:

1) Only one content management system to maintain etc.

2) The liability for any unsuitable postings is placed firmly back at
the editors themselves.

Regards, Dave.

Dave,

> I realise the PostgreSQL project is not the same as Vale Housing, but
> still, the same considerations must be made to some extent.

Not really.  It's easy enough for us to add a legal disclaimer to the Wiki
template.  Beyond that, we're an unincorporated OSS association.

> LOL!! So because it hasn't happened yet, it never will (or won't to us)?
> Besides, a quick Google shows that Wiki defacements are hardly unheard
> of, even if they can be rolled back.

Sure.  What I'm pointing out is that the defacements are not at a level which
hampers the use of Wikis.

> Reading your pros and cons, the only *real* advantage of a Wiki over
> some other CMS is that the would be editor/author needn't register to
> use the system first. Given that registering for such a site and waiting
> for a return email is likely to be more or less instant,

But it's not on Bricolage: registration of a new author needs to be done
manually by an adiministrator.   The workflow and permissions are too complex
otherwise.

> and only
> required upon the first use, I would rather use just one system for the
> whole site,

That's a powerful argument, though.

>and know that we do at least have a valid email address for
> each editor on the system (who would have had to agree to T&Cs upon
> registration).

I don't think we can enforce T&C, since there is no entity to enforce them.

> 1) Only one content management system to maintain etc.
>
> 2) The liability for any unsuitable postings is placed firmly back at
> the editors themselves.

Both valid.

We can compromise, here, though, you realize.   What if we got Bric up and
running, and then let the admins of the Bric site decide, after some use,
whether a Wiki was called for?  At that time, it would be more concrete and
less speculative.

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

On Jan 18, 2004, at 10:51 AM, Marc G. Fournier wrote:

> David, could you comment to Robert's questions below?
>
> On Sun, 18 Jan 2004, Robert Treat wrote:
>
>> stumbling block for techdocs. One thing that we do need is the
>> ablility
>> for users comments on articles, is there any provision for that?
>> Another thing that could come up would be user articles submitted in
>> pdf
>> form (I just added one yesterday), is there a provision for that?

No. Bricolage is entirely a back=end application. For users to comment
on articles, you'd have to do one of two things: Either implement
something for it on the front-end server (I'm sure there are plenty of
simple OSS solutions for this), or create some sort of gateway script
that takes a submitted comment and submits it to the Bricolage SOAP
server to be added to a document, and then triggering the republish of
that document.

For performance reasons, I recommend the former.

HTH,

David

On Sun, 18 Jan 2004, elein wrote:

> PS: I cannot run bricolage on my own server until I
> get upgraded to debian from old suse :-(

That isn't an issue, I just need someone to tell me that this is what we
should be working on and I'll get it setup over here ...

From what Steve said, it shouldn't be run on port 80 of the main site ...
can the port be changed, or does it need to run on a seperate IP
altogether?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

On Mon, 19 Jan 2004, Josh Berkus wrote:

> >and know that we do at least have a valid email address for
> > each editor on the system (who would have had to agree to T&Cs upon
> > registration).
>
> I don't think we can enforce T&C, since there is no entity to enforce them.

No, but it makes it easier to remove privileges, and avoids a protracted
argument about it ... no?

Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Marc,

> That isn't an issue, I just need someone to tell me that this is what we
> should be working on and I'll get it setup over here ...

From my experience, Bricolage needs its own (virtual) server, and preferably
its own machine.   It's not set up to share resources.

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

> -----Original Message-----
> From: Josh Berkus [mailto:josh@agliodbs.com]
> Sent: 19 January 2004 20:02
> To: Dave Page
> Cc: PostgreSQL Web Development Mailing List
> Subject: Re: [pgsql-www] Bricolage: Impressive
>
> Dave,
>
> > I realise the PostgreSQL project is not the same as Vale
> Housing, but
> > still, the same considerations must be made to some extent.
>
> Not really.  It's easy enough for us to add a legal
> disclaimer to the Wiki template.  Beyond that, we're an
> unincorporated OSS association.

Yes, and as such the entity that takes the hit of any legal action is
not going to be the board of any company, but probably whoever is
legally in charge of the servers - in this case, Marc.

> Sure.  What I'm pointing out is that the defacements are not
> at a level which hampers the use of Wikis.

<grin> Neither are defacements of IIS servers as a level which generally
hampers the use of them - but I bet you wouldn't install one...

> But it's not on Bricolage: registration of a new author needs
> to be done
> manually by an adiministrator.   The workflow and permissions
> are too complex
> otherwise.

Ahh, now that I don't know. Can it be streamlined with some custom code?
I assume it all basically comes down to adding the appropriate rows to
the relevant tables, so if we know all the basic settings to give to a
Joe Public editor then we can bypass the normal user management code...

> I don't think we can enforce T&C, since there is no entity to
> enforce them.

There must be some legal entity in control for the servers to even exist
(probably Marc/hub.org in this instance). If something defamatory about
Microsoft remained posted for some length of time because none of us
were around to remove it quickly, I'm sure there crack legal team would
figure out who to sue pretty darn quickly.

Besides, the idea is not to necessarily enforce the T&Cs by sueing
anyone who breaks them (though we can remove their account), but to show
that we have made best effort to ensure all users follow the rules.

> We can compromise, here, though, you realize.

Absolutely, and I will go with the majority decision in the end, however
I must put my thoughts forward so that all considerations may be, well,
considered!

> What if we got Bric up and
> running, and then let the admins of the Bric site decide,
> after some use, whether a Wiki was called for?  At that time,
> it would be more concrete and less speculative.

Well I think we should do that anyway, but having a streamlined editor
registration system on Bric vs. a Wiki is a matter of policy in some
ways as well as a technical issue.

Regards, Dave.

On Mon, 19 Jan 2004, Josh Berkus wrote:

> Marc,
>
> > That isn't an issue, I just need someone to tell me that this is what we
> > should be working on and I'll get it setup over here ...
>
> From my experience, Bricolage needs its own (virtual) server, and preferably
> its own machine.   It's not set up to share resources.

k, seperate VM isn't an issue ... but what is it doing that it needs its
own machine?  God, I thought Java programs were the worst, you are saying
that this needs more then jakarta-tomcat processes?

David?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Marc,

> k, seperate VM isn't an issue ... but what is it doing that it needs its
> own machine?  God, I thought Java programs were the worst, you are saying
> that this needs more then jakarta-tomcat processes?

Probably not, no.

It does need a seperate VM because of all the Perl stuff and the static
mod_perl in Apache.

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

On Mon, 19 Jan 2004, Dave Page wrote:

> There must be some legal entity in control for the servers to even exist
> (probably Marc/hub.org in this instance). If something defamatory about
> Microsoft remained posted for some length of time because none of us
> were around to remove it quickly, I'm sure there crack legal team would
> figure out who to sue pretty darn quickly.

Actually, its not that bad ... it just happened to us recently, where we
go ta 'cease&desist' order from the legal dept of a company ... turns out
that RackSpace still hasn't removed us as owners of our old IPs, and the
current owners are running 'illegal porn' off of them :(  I think that
legally they have to do a request to remove the content *before* suing,
and I think it becomes even more difficult for them where the servers
*aren't* in the US, nor fall under the US legal system ...



----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

On Mon, 19 Jan 2004, Josh Berkus wrote:

> Marc,
>
> > k, seperate VM isn't an issue ... but what is it doing that it needs its
> > own machine?  God, I thought Java programs were the worst, you are saying
> > that this needs more then jakarta-tomcat processes?
>
> Probably not, no.
>
> It does need a seperate VM because of all the Perl stuff and the static
> mod_perl in Apache.

That's doable with the current VM as well, as mod_perl is already
installed ... the only issue that I could see is the port 80 that Steve
mentioned ...

But, the thing with putting it onto its own VM is that it makes it easier
to provide ppl like Elein and Steve access without having access to the
main servers ...

If we are all in agreement that this is the direction we want to go, then
I can get the VM for this setup tomorrow ... who will/should be given
"root" to that VM?  Elein?  Steve?  Josh?  Let me know ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

I would definitely like access.  I don't have a postgresql
login, though.  Steve--let's coordinate off list?

--elein

On Mon, Jan 19, 2004 at 05:09:09PM -0400, Marc G. Fournier wrote:
> On Mon, 19 Jan 2004, Josh Berkus wrote:
>
> > Marc,
> >
> > > k, seperate VM isn't an issue ... but what is it doing that it needs its
> > > own machine?  God, I thought Java programs were the worst, you are saying
> > > that this needs more then jakarta-tomcat processes?
> >
> > Probably not, no.
> >
> > It does need a seperate VM because of all the Perl stuff and the static
> > mod_perl in Apache.
>
> That's doable with the current VM as well, as mod_perl is already
> installed ... the only issue that I could see is the port 80 that Steve
> mentioned ...
>
> But, the thing with putting it onto its own VM is that it makes it easier
> to provide ppl like Elein and Steve access without having access to the
> main servers ...
>
> If we are all in agreement that this is the direction we want to go, then
> I can get the VM for this setup tomorrow ... who will/should be given
> "root" to that VM?  Elein?  Steve?  Josh?  Let me know ...
>
> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664
>
> ---------------------------(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

Marc G. Fournier said:
>> It does need a seperate VM because of all the Perl stuff and the static
>> mod_perl in Apache.
>
> That's doable with the current VM as well, as mod_perl is already
> installed ... the only issue that I could see is the port 80 that Steve
> mentioned ...

It can be set up to run on a port other than 80 -- that's what I'm doing on my
server.

You might want to try setting it up on a different computer first, though, for
the experience -- when I tried to set it up on mine (I was attempting to do a
virtual host on the same port), I accidentally caused Bricolage to answer all
queries for all virtual hosts, and if my sites had higher traffic, people
might have noticed.  :-)

Also, be ready to install a LOT of Perl modules.

The main issue to consider with Bricolage are the memory requirements -- I
think the docs say that it takes something like 25MB per Apache child.
Looking at my server, I see one child at 30MB.  So be sure that there's plenty
of RAM available.

> If we are all in agreement that this is the direction we want to go, then
> I can get the VM for this setup tomorrow ... who will/should be given
> "root" to that VM?  Elein?  Steve?  Josh?  Let me know ...

The only people who should need direct access to the machine are the people
who will be maintaining any technical aspects of it.  All content and
template/layout development and publishing (except deleting files once they're
published) can be done through the interface.

I'd be fine with being the (or one of the) main people doing technical
maintenance on this server, but I wouldn't want to be the only one.  I could
help get someone else up to speed, though, if that would help.  (Elein?)

Hope this helps,

Steve Simms
Database Developer & Administrator
Medical Media Systems, Inc.

Josh Berkus said:
> If Steve is up to templating, I will happily work on porting articles.

I'd be happy to do the templating -- compared to the Mason code I normally
deal with, this should be simple.  My hangup at the moment is coming up with
the structure.  If Elein, Josh, etc. could help me come up with a revised set
of categories for the articles, that would be very helpful.

The existing TechDocs site looks like it was modified as articles were added,
with the result that I have a hard time finding things on that page.  Now that
we have a fairly large number of articles, it seems like it would be worth
taking the time to take another look at the category structure.

Also, it might be worth moving pre-7.3 articles into their own subcategory --
maybe by having a set of categories for version-specific articles.  When I
first visited the PostgreSQL sites, I thought the project was no longer in
active development because of the large number of old articles that were
prominently linked.  This would help, as would getting new articles.  :-)  We
certainly shouldn't remove them altogether, though -- I, for one, was
maintaining a 7.1.1 install of PostgreSQL until a couple of months ago, and
those articles were helpful.

> Robert: since what Bric does is build HTML pages, it is entirely possible to
> "plug in" PHP applications as blocks of HTML text.   Comments could be
> supported this way, as well as a Wiki (which I also believe we should have).

Correct.  We'd just have the Bricolage "burner" include the relevant code to
fire up the relevant apps.  This *will* impact our ability to have mirrors,
though, for the TechDocs site, I don't imagine this is terribly important.

Steve Simms
Database Developer & Administrator
Medical Media Systems, Inc.

On Jan 19, 2004, at 3:54 AM, Oleg Bartunov wrote:

> what I'd like to see is a built in search facility, so once document
> has approved for publication, it could be searchable. It's nice feature
> and we use it in our CMS (also, Mason based) and PostgreSQL has
> contrib/tsearch2 (I'm one of the authors) and OpenFTS as a middleware,
> so I don't see any problem to add search to Bricolade.
>
> This will solve .postgresql.org problem with search engine if -www
> will decide to go with Bricolade.

Bricolage is a back-office application, not front end. It has SQL-style
search, but it's just for users of the application. Once you publish a
document, it's entirely outside of Bricolage -- it distributes the
XHTML files to your Web server. If you need search on the front end,
it'll have to be a different product.

I hear that SWISH-E works pretty well.

Cheers,

David

On Jan 19, 2004, at 12:44 PM, Marc G. Fournier wrote:

> k, seperate VM isn't an issue ... but what is it doing that it needs
> its
> own machine?  God, I thought Java programs were the worst, you are
> saying
> that this needs more then jakarta-tomcat processes?
>
> David?

It typically starts up using around 25MB per process (shared). It's not
uncommon for processes to swell upwards of 50MB or more. Then there are
the PostgreSQL processes.

Hey, you want a lot of functionality, you got to pay for it.

Cheers,

David

On Jan 19, 2004, at 5:34 PM, Steve Simms wrote:

> The only people who should need direct access to the machine are the
> people
> who will be maintaining any technical aspects of it.  All content and
> template/layout development and publishing (except deleting files once
> they're
> published) can be done through the interface.

Actually, if you publish a document with an expire date and you have
bric_dist_mon running on a cron job, the files will be deleted from the
Web server. :-)

Regards,

David