cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: Type in Documentation..
Date Wed, 15 Dec 1999 09:08:02 GMT
On Tue, 14 Dec 1999, Stefano Mazzocchi wrote:
> 3) bug database: we'll have bugzilla or jitterbug installed pretty soon
> on locus (I hope)

Yes.  I'm in New York at the Bazaar right now, but am still working on
getting bugzilla up on locus.  You can see my current status if you have a
locus account and do a "locate bugzilla" I think.

> question: why don't we XML-ize everything and use Cocoon/Stylebook for

First, you need to explain to me how to make this system work for mirror
sites.  Basically, the Apache web site is flat text and images, which
makes it very easy to set up a mirror site, and we allow rsync and cvsup
to be used to synchronize the mirror sites extremely efficiently.  We can
not ask mirror sites to run any software other than stock Apache, IMHO,
and nothing that could potentially open up their server to a vulnerability
- no CGI scripts, no server-side includes that could compromise things,
etc.  You can call it old-fashioned, but if we want real mirror sites we
need to be very conservative in our demands.  That conservancy is what's
led to the couple-hundred mirrors we have.  =)  

> We could "croned"
> - stylebook to regenerate the web site (as soon as a 1.2 JDK is
> installed on locus, we should try to install the latest Sun JDK for
> linux on the FreeBSD linux emulation layer). Something like the
> script that Jon and I wrote for last year.
> Stuff like (pseudoscript):
>  for project into project-list
>   cvs update $(project)/xdocs
>   if something changed
>    ant generate-$(project)
>   fi
>  rof

I would much prefer to see something like this done pre-commit to the
-site CVS module than afterwards.  For example, look how we generate the
listing of mirrors - we have a flat text database that we edit, and then
run a script to generate an index.html file.  When we edit the database,
we run the script, then do a

  cvs commit mirrors.txt index.html

This, in my opinion, is a good design pattern to follow.  It suggests that
files should only be updated when their source is updated and when there's
actual change (in fact CVS will enforce that =).  

> - cocoon special producers to XML-ize stuff like:
>     bugs (using SQL producer out of MySQL)

Bugzilla is being installed.  I'm looking forward to someone writing a
servlet-based replacement for it - is interested in putting
resources towards that.  However, I do not think XML is ideal as the
storage format for these bugs; I think relational databases are the best
native format for bug data.  However when it comes to *sharing* bug data
between applications, XML may make an ideal transfer format.

>     mail archives (calling command line stuff?)

I am about to enter a project into sourceXchange to build a servlet-based
replacement for Hypermail, one that operates on an indexed mbox file
rather than filling up the disk with thousands of independent flat files.
Stay tuned.


View raw message