forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Morrison" <>
Subject RE: analysis paralysis :-)
Date Tue, 26 Feb 2002 20:21:43 GMT
> From: Stefano Mazzocchi []
> Steven Noels wrote:
> > where do we go from here?
> >
> > 1) 'force' the entire apache community into maintaining xml docs for
> > their project website: should be no problem
> There is no alternative: separation of concerns is king if we want to
> keep the docs scalable... otherwise this project will become the
> bottleneck and I don't want this.

Without doubt they should use xml.  Question is - should they all *have*
to use the same DTD/schema?

> > 2) force to run tomcat/cocoon: seems to be a
> > problem, in terms of:
> >    - need: for static content, this is overkill
> >    - platform: not sure whether machines are up to spec for this
> >    - people: are we ready (teamwise) to support a high-visibility
> > website
> These are all good points.
> My original idea was to run Forrest and Gump from ''
> (and have it renamed ''), this will not be a
> high-visibility web site, but a medium visibility testbed to show the
> potentials of the platform... in order to show what
> functionality we could have if we allowed dynamic technology on Apache
> (finally!)

Testbed first.

> BTW, PHP is a official ASF project but runs entirely on their own
> resources.
> moreover, all jakarta mail lists run on nagoya, which is a Sun-owned
> machine (a big E4500, some 200K$ worth of hardware, sitting there
> running Bugzilla, doing gump builds and sending jakarta email, with load
> that never gets higher than 0.01, at least this is what Pier told me
> since I don't have an account on that machine... but I know Sam does)

Just out of curiosity - what webserver/servlet engine do they have
running?  (I've got to 'port' cocoon2 onto an E10K (not sure about the

> Sam, what's your view on this.
> > 3) incremental development:
> >
> > are we absolutely positively in need of a dynamic website with browser
> > negotiation from the beginning? in need of user comments/write-ins and
> > other dynamic features?
> >
> > or should we start incrementally and start out with the visible part,
> > i.e. 'portal look & feel' and aggregation from different information

Is this going to be a portal?  News to me :)  Wouldn't mind if it is, but
login may become a problem unless it's either an apache id or guest.

> > sources - staying static for as long as possible?
> >
> > given the state of the current wildlife park, I tend to
> > say we should start slowly and try to gather people around the same
> > website structure and look&feel, and withhold all dynamic features until
> > we have a new based on forrest cocoon generation
> >
> > and we should decide so upfront because it is difficult to start working
> > otherwise
> Ok, I change my -1 on staticity to a -0, but I *want* a clean URI
> space... this will require Forrest to produce .htaccess files with
> mod_rewrite rules, but I think this isn't that hard to do. We could also
> perform browser negotiation using those rewrite rules.
> What do you think?

I'm -0 overall...

+1 for clean URI - that's a given.
static/dynamic... not so sure, after all dynamic's the whole point of
Cocoon (for me at least).  I think I'd sooner go for dynamic and judge
the performance, we can always wget -m and host that if it's not upto the
job (and I'd be suprised if it isn't...).

Anyone else?


View raw message