forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <j3322...@yahoo.de>
Subject Re: forrestbot: security and trust
Date Sat, 13 Jul 2002 16:04:39 GMT
Steven Noels wrote:
> nevertheless, I don't think too many people have set up Gump locally, 
> they are happy with the service Sam is providing

But then, Gump does not write important stuff back.

> this remote obsession came when finding out how many copies of common 
> jars & infrastructure tools are dispersed across cvs.apache.org: loads 
> of copies of xalan, xerces, ant, etc etc
> 
> I live with the assumption people are not eager to install a full-blown 
> Cocoon runtime environment if the complexity of their documentation does 
> not justify that - maybe they would be happy to find out that the 
> forrestbot does it all for them without too much project-related 
> dependencies

You need only one installation of forrest per server. I don't
think every *project* should get a local copy. This is what I
generally rant about: you cannot expect every document writer
to install a forrest at home, you need a more lightweight
environment. But is certainly possible to have an installation
at the publishing point - the server - for publishing
purposes.

I imagine several subpackages of forrest:
- DTDs, skin(s), XSLT and build files for local doc
   building: base provided by forrest, may be augmented
   by project and is managed and distributed by the
   project. May contain pre-built files which require
   special tools, the tools are not by default distributed
- publishing environment: get doc source from CVS (remote
   or local), build docs, put them into the server
   publishing space (remote or local). May include doing
   stuff which is not done automatically at home in general,
   like generating indexes, directory views, rendering
   images and 3D buttons for the navigation bars or whatever,
   and includes doing project spanning stuff, like doing
   cross project links, link checks, or something else.
- advanced stuff which probably requires running Cocoon live

I think it's a good idea not to muddle these aspects too much.

It will lead to many copies of the base docs package (DTDs,
skins etc.), the same way everybody currently has its own
copy of ant, xerces, xalan etc. Because interfaces change
asynchronly, this is hard to change.
Another aspect is that users are often happy if they can
download a package, unpack it somewhere and it just runs.
Setting environtment variables or keeping a certain directory
structure is already too much. The only reasonable
assuption is that either "java" starts the JVM or JAVA_HOME
is set properly.
Even many casual developers and doc writers are not too
keen on having to download half a dozen other packages
and shuffle files into the correct directories, perhaps
renaming them on the way, only in order to recompile
the only fix they will ever make.

As for the docs, I could imagine the skin distributed by
the project is a pure text skin, just enough to proof read
the docs. Well, spacer gifs, logos, and other small pictures
don't take up too much space either. If skins contain
3D-buttons or other automatically renderend graphics with
project data, it is probably necessary to check in the
changes, wait for forrest to do it's turn (or trigger it),
and then get the advanced stuff back.

J.Pietschmann


Mime
View raw message