You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/10/27 00:52:29 UTC
Re: New ASF site was Re: New Apache XML Site! :-)
I'm ccing this also to Forresters.
Justin Erenkrantz wrote:
> [ Moving this to site-dev@ which is the appropriate list. ]
>
>> Also, I have also made a Forrest version of the main Apache site,
>> what do you think, can it be done?
>>
>> http://cvs.apache.org/~nicolaken/apache-www/build/site/
>
> I would say 'no' until certain things are resolved.
>
> Graphically, I much prefer the uni-color white background. There is
> also something about repeating the links at the top of the content pane
> that strikes me as funny. (I think we might be able to fix these issues.)
Sure. The current version is the best we got now, but it will get better
and better with more feedback. :-)
> I've brought up the build system issues on general@commons. If Forrest
> requires a separate step for building it (apart from what we already do
> with anakia), I'm going to be against it.
Errr, as a "separate step", you mean having to install-build Forrest it
first?
From the commandline it basically works as Anakia...
> We really can't introduce
> another requirement. We already have enough people who refuse to update
> the www.apache.org (or httpd.apache.org) sites because they refuse to
> work with any Java-based document systems.
:-/
> So, I don't expect that we
> can require the people who modify our site to go download Forrest
> snapshots, tweak environment variables, run special Java scripts, etc.
> It's bad enough as it is. So, if we do this, we have to be able to run
> it with ./build.sh alone.
It's not a problem, it's just a matter of defining on how to do it, and
then we will make it avaliable.
How about a build.sh script in each site CVS that does this:
1 - checks if forrest is installed globally
2 - if not checks if it's installed in the dir of the site to build
2 - if not it asks if it's ok to download it
3 - downloads the Forrest jar with wget
4 - unpacks it
5 - runs Forrest
This way we don't strain CVS, don't have to checkin Forrest and users
that already have forrest installed use it normally.
But of course Java has to be installed...
-oOo-
There is another possibility though.
With Forrest we have created for this purpose a "bot" that simply checks
out a series of sites from CVS, runs the build, and uploads them to the
website.
It's been working for Forrest by publishing the forrest site
automatically on Sourceforge and outerthought.net since months now, with
no problem.
http://outerthought.net/forrest/
http://www.krysalis.org/forrest/
This could be an option.
> Yet, my biggest concern is how it looks in a text-only browser.
> xml.apache.org looks awful in links, while www.apache.org is browsable
> with links (rather clean). So, before we go on a crusade to change even
> more of the ASF sites to Forrest, I would like to ensure that we keep
> text-only browsers fully supported. -- justin
Ok, I'll tell this to our skin writers.
We tried using CSS without tables but it simply crashed Netscape 4.7.
Actually, the real goal of Forrest is not to generate the site
statically, that's just a temporary _hack_, a showcase to get people see it.
The real goal is to use Forrest *live*, thus serving the *best* content
to each browser, by doing separate transformation based on the request,
a thing that a single graphics cannot give.
It will make it possible also to make registered users add comments on
the pages, and add documentation *without* having to build documentation
(*ugh*) or see xml (*double ugh*), since we are near to do in-place
editing in Mozilla and Netscape.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: New ASF site was Re: New Apache XML Site! :-)
Posted by Steven Noels <st...@outerthought.org>.
Justin Erenkrantz wrote:
> I would be against such a bot in use for ASF sites.
>
> There are times when we want to check in a change and do not necessarily
> want to propogate the change immediately (say a pending security
> release). There are also times when we want an immediate deployment -
> waiting for a bot could be painful (activating the bot by trigger could
> be useful but introduces the first problem).
>
> I'm also concerned about security risks of a remote cron job that copies
> the files to production. Remember that we can't do the generation on
> the production site.
>
> So, I would strongly prefer that we maintain manual deployment.
Then why should we use CVS as a synchronization mechanism, if rsync and
friends exist, and could be packaged in a user-triggerable script as
well - maybe a webapp so that people can trigger updates through a
special, authenticated URL...?
The main problem is CVS's awkward handling of directories and removal of
historical cruft. It is well suited for source code development, but not
as a staging mechanism for websites, IMO.
> As I bet you are aware, there will be major performance considerations
> if you go down this route. I would be reluctant to move away from
> static pages in any ASF environment. In the past, I have worked with
> sites that used Java/XML/XSLTs to dynamically generate the pages and was
> bitten by their lack of scalibility. The approach the ASF has tried to
> promote on its webpages is static translations rather than dynamic
> translations. I believe it fits well in our deployment model.
>
> Please remember that the ASF sites handle approximately 2-3 million hits
> a day (may well be much more by now). Dynamic pages may make sense for
> small sites, but I'd have to be sold on doing this for such a large site
> that has severe resource constraints. We have no money to buy a Fire
> V480 - we're lucky we have daedalus/icarus. -- justin
And I have been suggesting recently to add additional servers to the ASF
serverpark, since getting access to other servers than daedalus & icarus
is hard to get. We were playing with the idea to use proxy_pass to proxy
dynamic resources. Maybe that could be the right balance between dynamic
websites and static delivery.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
Re: New ASF site was Re: New Apache XML Site! :-)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Justin Erenkrantz wrote:
[...]
> I'm also concerned about security risks of a remote cron job that copies
> the files to production. Remember that we can't do the generation on
> the production site.
>
> So, I would strongly prefer that we maintain manual deployment.
The Xml.Apache site is gotten from CVS and updated on the production
site using a cron job...
>> The real goal is to use Forrest *live*, thus serving the *best*
>> content to each browser, by doing separate transformation based on
>> the request, a thing that a single graphics cannot give.
>
> As I bet you are aware, there will be major performance considerations
> if you go down this route. I would be reluctant to move away from
> static pages in any ASF environment. In the past, I have worked with
> sites that used Java/XML/XSLTs to dynamically generate the pages and was
> bitten by their lack of scalibility. The approach the ASF has tried to
> promote on its webpages is static translations rather than dynamic
> translations. I believe it fits well in our deployment model.
.
> Please remember that the ASF sites handle approximately 2-3 million hits
> a day (may well be much more by now). Dynamic pages may make sense for
> small sites, but I'd have to be sold on doing this for such a large site
> that has severe resource constraints. We have no money to buy a Fire
> V480 - we're lucky we have daedalus/icarus. -- justin
More than fair.
I got carried away... ;-)
Would it be doable if Forrest generated the content statically for all
the browsers and Apache directed the browser to the correct pages using
the request header?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: New ASF site was Re: New Apache XML Site! :-)
Posted by David Crossley <cr...@indexgeo.com.au>.
Justin Erenkrantz wrote:
> Nicola Ken Barozzi wrote:
>
> > With Forrest we have created for this purpose a "bot" that simply
> > checks out a series of sites from CVS, runs the build, and uploads
> > them to the website.
>
> I would be against such a bot in use for ASF sites.
>
> There are times when we want to check in a change and do not
> necessarily want to propogate the change immediately (say a pending
> security release). There are also times when we want an immediate
> deployment - waiting for a bot could be painful (activating the bot
> by trigger could be useful but introduces the first problem).
There are various ways to initiate the forrestbot.
It could also be configured to build to a staging area
for QA. If it does not yet suit users needs, then we will
add functionality. As with all projects, we need users.
Above all we need feedback and requirements, so keep on.
> I'm also concerned about security risks of a remote cron job that
> copies the files to production. Remember that we can't do the
> generation on the production site.
So we would build projects on the remote machine
with Forrest, and use rsync to publish (over ssh
if needed) or scp. Does that suit?
> So, I would strongly prefer that we maintain manual deployment.
>
> > The real goal is to use Forrest *live*, thus serving the *best*
> > content to each browser, by doing separate transformation based on
> > the request, a thing that a single graphics cannot give.
Ken, the "real" goal of Forrest is to meet diverse
needs. Live run is one of those, but not the main.
Forrestbot and local build are equally important.
I am sure that you know this, as you have been with
us since the early days. I think that you are getting
exited and over-zealous in your promotion of Forrest.
I do understand - it is brilliant. Please settle down.
> As I bet you are aware, there will be major performance
> considerations if you go down this route. I would be reluctant to
> move away from static pages in any ASF environment. In the past, I
> have worked with sites that used Java/XML/XSLTs to dynamically
> generate the pages and was bitten by their lack of scalibility. The
> approach the ASF has tried to promote on its webpages is static
> translations rather than dynamic translations. I believe it fits
> well in our deployment model.
That is why Forrest has diverse capabilities to
suit various needs.
> Please remember that the ASF sites handle approximately 2-3 million
> hits a day (may well be much more by now). Dynamic pages may make
> sense for small sites, but I'd have to be sold on doing this for such
> a large site that has severe resource constraints. We have no money
> to buy a Fire V480 - we're lucky we have daedalus/icarus. -- justin
These frustrations have actually fuelled Forrest's
development. We have had to find ways to work with such
real-life situations. IMO, static pages are the way to
go, perhaps using some well-designed dynamic bits where
appropriate.
--David
Re: New ASF site was Re: New Apache XML Site! :-)
Posted by Justin Erenkrantz <je...@apache.org>.
--On Sunday, October 27, 2002 12:52 AM +0200 Nicola Ken Barozzi
<ni...@apache.org> wrote:
> With Forrest we have created for this purpose a "bot" that simply
> checks out a series of sites from CVS, runs the build, and uploads
> them to the website.
I would be against such a bot in use for ASF sites.
There are times when we want to check in a change and do not
necessarily want to propogate the change immediately (say a pending
security release). There are also times when we want an immediate
deployment - waiting for a bot could be painful (activating the bot
by trigger could be useful but introduces the first problem).
I'm also concerned about security risks of a remote cron job that
copies the files to production. Remember that we can't do the
generation on the production site.
So, I would strongly prefer that we maintain manual deployment.
> The real goal is to use Forrest *live*, thus serving the *best*
> content to each browser, by doing separate transformation based on
> the request, a thing that a single graphics cannot give.
As I bet you are aware, there will be major performance
considerations if you go down this route. I would be reluctant to
move away from static pages in any ASF environment. In the past, I
have worked with sites that used Java/XML/XSLTs to dynamically
generate the pages and was bitten by their lack of scalibility. The
approach the ASF has tried to promote on its webpages is static
translations rather than dynamic translations. I believe it fits
well in our deployment model.
Please remember that the ASF sites handle approximately 2-3 million
hits a day (may well be much more by now). Dynamic pages may make
sense for small sites, but I'd have to be sold on doing this for such
a large site that has severe resource constraints. We have no money
to buy a Fire V480 - we're lucky we have daedalus/icarus. -- justin