forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Noels" <stev...@outerthought.org>
Subject RE: analysis paralysis :-)
Date Tue, 26 Feb 2002 20:26:32 GMT
Stefano Mazzocchi wrote:

>
> 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.

+1, of course

> > 2) force root@xml.apache.org 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 'gump.covalent.net'
> (and have it renamed 'forrest.covalent.net'), 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 root@apache.org what
> functionality we could have if we allowed dynamic technology on Apache
> (finally!)
>
> 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)
>
> Sam, what's your view on this.

Fair enough, and let me restate that I'd love to see Forrest go live and
dynamic on top of Cocoon in the future. Point is that we should at least
have a decent project set-up/kick-start without getting slowed down by
continuously restating requirements and goals.

We all want the same in the end, but I'd prefer to start simple and keep
the dynamic stuff for phase 2 **while maintaining URL space clean and
consistent** (which is precisely the power Cocoon can provide us with)
(not that *I* need to tell you that, of course ;-)

>
> 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?

Browser negotiation is dynamic stuff, we should do that when Cocoon is
running underneath. Given the amount of politics and work coming up, I'd
say we start without browser negotiation. After all, even a consistent
look across xml.apache.org will already be quite revolutionary, and none
of the current project sites is doing much towards browser capabilities.

1) convince everybody to let forrest (static) take care of their project
website, showcasing the new 'portal' *look&feel*, generating static html
for xml.apache.org
2) once this has been taken care of we can make a switch-over using the
exactly same sitemap but now running dynamically on top of Cocoon
(nagoya)
3) after this transparent switch-over we start adding new (dynamic)
stuff until nobody wants to see anything else ;-)

Phase 1: Spring
Phase 2: Summer
Phase 3: Q3/4 and further on

How about this?

</Steven>


Mime
View raw message