Обсуждение: 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