Actually I prefer the Forrest version in Lynx.
IMHO, links produces better rendering of documents than lynx. The most noticable difference is that links can handle columns correctly. links follows closer the intention of the site layout than lynx. Perhaps you have never tried links (http://links.browser.org/)? (elinks is the latest iteration of links code base.) (This is the second time a Forrest developer has confused lynx and links.)
My problem with the Forrest skin is the abundance of spacer images. I believe they add no value, and for me, they make the site unusable (I display all links to images). The avalon-tigris skin does not suffer from the spacers.
We *must* have the source version-controlled as I'm not going to be modifying forrest-marked-up text myself - that contradicts forrest's original purpose.
Why may I ask?
From what I can see (as witnessed by the various ASF sites now usingForrest), Forrest's generated HTML files are not clean and don't have indentation. Therefore, I would not prefer to work on its generated HTML files.
As a point of reference, please compare anakia-generated www.apache.org HTML source with the forrest-generated xml.apache.org HTML source. IMHO, the anakia-generated HTML is *vastly* superior to the forrest-generated HTML. It might just be possible to work off of the anakia-generated HTML, but I don't think that's really feasible in forrest (as demonstrated by xml.apache.org).
Perhaps the original xml.apache.org XML input is just poorly formatted. Perhaps.
Anyway, we are working on both wiki-like editing and in-browser editing, so it won't be an issue in the near future :-)
I'd never use those mechanisms on apache.org as they don't allow proper authentication. (Well, it might if we used SVN not CVS.) A server shouldn't be changing content solely because of an activity done on a web form. That'd be incredibly insecure for us.
Our webserver shouldn't allow modifications - only committers can do commits. And, committers can only commit with CVS on cvs.apache.org. Note, the CVS and web servers are distinct in the ASF infrastructure, so this introduces another host of problems.
SVNWiki is the exception here because it ties in with the SCM and Subversion can authenticate via HTTP authentication mechanisms. CVS allows no such thing to occur.
We would run Forrest cron job on another server, and publish it there. Daedalus synchs his version from that other server (ie pull, not push).
How does it pull? rsync?
I've mentioned before the severe drawbacks of a pull-based synch model that have nothing to do with technical aspects. Namely that I forfeit control of when the site is updated and I can't properly embargo a website change. The resulting 'automated' process that dealt with this would be much more complicated than the manual 'cvs up' process.
Note, I'm a *very* demanding user. So, please don't take any of my comments personally, but I expect a lot from my tools. -- justin
