Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: forrest-dev@xml.apache.org
Message-ID: <3DCA35AA.4000602@apache.org>
Date: Thu, 07 Nov 2002 10:43:06 +0100
From: Nicola Ken Barozzi <nicolaken@apache.org>
Reply-To: nicolaken@apache.org
Organization: Apache Software Foundation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: general@commons.apache.org,  forrest-dev@xml.apache.org
Subject: Re: Commons site prototype up
References: <20021106232612.A4104@apache.org>
 <20021106233708.A7538@apache.org> <2147483647.1036627327@localhost>
 <3DCA2224.9090301@apache.org> <2147483647.1036631894@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Justin Erenkrantz wrote:
> --On Thursday, November 7, 2002 9:19 AM +0100 Nicola Ken Barozzi 
> <nicolaken@apache.org> 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 using 
> Forrest), 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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------