forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <baro...@nicolaken.com>
Subject Re: on second thought: forrest must start dynamic?
Date Mon, 25 Feb 2002 13:45:04 GMT
From: "Stefano Mazzocchi" <stefano@apache.org>

> Nicola Ken Barozzi wrote:
> > How about some initial javascript and then /browser/mozilla/ URI hack?
>
> No way, do you think that is a clean URI space that will last for the
> next decades?

Now I understand.
Ok, so for the REAL hack ;-)
Make every page a frame that calls the appropriate document inside.
This way we have clean URIs, because the real ones ( /browser/mozilla/ ) are
inside, ie hidden.
Not that I love it, but it works ;-)

> > As
> > the previous possible solution the Ant task needs also to make CLI start
> > with n-browser links for every project.
> > In this way, all is statically generated, and the routing to the
appropriate
> > "mirror" is done by javascript, client side, on entering the site, or
maybe,
> > with a check in every page.
> > I'm -1 for starting dynamic, I even doubt we Forrest will ever get there
> > soon.
>
> Please, explain why.

My informal -1 should have been -0. See below.

> > > Anyway, having static snapshots for mirroring purposes is a must or
> > > Apache will never adopt forrest globally.
> >
> > +1
>
> I've asked Brian and he's -1 on running Cocoon on xml.apache.org since
> the machines are already overloaded (or close to be), but I was
> expecting that.

This is why. My humble opinion is that more we get away from
non-pregenerated stuff, the faster we will get accepted. Then going dynamic
could be a bit easier.

> His point is that we are serving static resources anyway.... what many
> of you miss to see is the fact that this *static serving* operation is
> *very* limiting.

For what?
As you know, the quality of a process is determined by the worst component.
Since IMHO information other than in the mailing lists and Bugzilla changes
daily, a faster update cycle is not top priority.
Anyway, I would LOVE to see Cocoon serving it, because we would live on our
own flesh the problems Cocoon can have, like the core Apache guys do with
Apache proper itself.

> And we should come out of this black hole.

How?
Hmmm...
How about buying the machine ourselves?
I can spend some bucks on it, and are pretty sure many on the Cocoon list
could say the same.

What do you think?

--
Nicola Ken Barozzi                 barozzi@nicolaken.com
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message