Justin Erenkrantz wrote:
--On Thursday, November 7, 2002 9:19 AM +0100 Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote:
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.)
Actually, I saw the question, but I missed your previous explanation, sorry.
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.
The Forrest skin started as a CSS skin only.
The problem is that Netscape 4.x crashes on some CSS, and to have the best possible user experience with all browsers, we resorted to using some hacks, while keeping them at a minimum. All the discussions are on the mailing list archives.
Currently we are discussing about resorting again to CSS-only, but we're afraid about Netscape 4 problems and poorer site.
Suggestions?
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.
Oops, I read your comment the other way round, I agree with you. Nobody should ever work on generated HTML files, so it's not a problem.
Anyway, if it's a user request we can easily put it in the skin stylesheets indent="true", no big deal.
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).
If this prevents people from wotking on the generated docs, good ;-)
Perhaps the original xml.apache.org XML input is just poorly formatted. Perhaps.
This is one thing. The other is that the Forrest skin is not yet self describing with comments on the various sections.
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.
Locally I mean.
ATM you can run forrest locally and see real-time results of your edits through localhost:8888 since we embedded a web server.
The wiki works on this system.
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.
Actually, having such a process doesn't stop me from publishing a version before the cron kicks in.
In the Jakarta site and Xml site CVSes, there *is* a cron job that picks up the contents, so I don't see the difference in this case.
The real difference is that I don't have to generate the stuff manually, but for the rest it's exactly the same.
It prevents users from touching the generated docs instead of the sources (you know how saving and updating double information sucks generally).
Also, it has been noted that the automated process can be made to update a "dev" version of the site, for staging purposes or the like.
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
Actually, I'd like to engage in this even more, because demanding users help make the best products :-)
So let's get these things sorted out, all of the Forrest developers are hungry for user feedback (witness 3 developers rushing for a reply on the same subject lately).
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------