forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: forrest2 and the future
Date Wed, 22 Nov 2006 10:57:42 GMT
Tim Williams wrote:
> First, great work on this.  I feel I was pretty tough - for good
> reason - when the idea first presented itself.  I now feel like we've
> got the basis for some concrete feedback.

I totally respect your "toughness" it makes one question ones own 
belief. That's the point of community development. It is a pleasure to 
have people like yourself (and the many others who discussed the 
original thought experiment).

> Now that I'm able to get the vision, I'm wondering what the way ahead
> is.  I realize we've had very little feedback from the rest of the
> community but I'd like to hear your concept.  Is this codebase to seed
> thought or to be a foundation?

To seed thought. If some of it can be reused then all well and good. 
However, I will not stand in the way of throwing it out and doing 
something better.

> I ask for several reasons:
> o) I think we've got a good situation where a Forrest Tuesday might be
> in order to get everyone on the same page to provide feedback.

Probably a good idea, but not until the new year. We don't need to rush 
on this, we need to get 0.8 out and we need to give people time to look 
at the experimental stuff in whiteboard.

> o) I wonder whether it's worth contributing to the rather obvious
> holes that currently exist.

Depends on how much of the current code your gut tells you can be reused 
and if you want to work on experimental stuff that may get thrown out.

I'd be very happy to welcome contributions of any kind. If the community 
sees value in it then the code will survive.

> o) I wonder whether you've got much invested in this particular
> codebase and thus aren't willing to shift so much OR you're pliable?

Everything is open to discussion.

> For example, I dont' particularly care for the implicit protocol
> pipelining and would rather a more explicit approach/grammar.  I think
> the need to make matching decisions on Servlet parameters is
> essential.  Etc.

Actually, this is one of the key things that brings benefit to this 
work, IMHO. The idea is you drop in a document, make a request and out 
comes what you want. No need to worry about what path through the system 
is taken, all you need to do is make sure the input can be handled, and 
the output can be handled and that is it. In other words, no programming 
of pipelines is required the user need know nothing about them.

It does make debugging more difficult, but that's easily addressed by 
providing a facility that, given a document request, outputs what the 
processing pipeline would be. E.g. asking for 
helloWorld.xml.forrestPipeline would give an output something like:

<request uri="helloWorld.html">
    <source uri="helloWorld.xml" required="false" present="false"
            matchingpattern = "(.*)/(.*)\.xhtml2"/>
    <source uri="helloWorld.xhtml2" required="false" present="true"
            matchingpattern = "(.*)/(.*)\.xhtml2"/>

   <inputPlugin id="xhtml2"/>

   <outputPlugin id="html"/>

I appreciate this seems really strange, but it is extremely powerful 
once you get the hang of it.

One other major advantage that I see in this approach is that the 
definition language is now the language of whatever container we are 
using. We can replace the container very easily as it's dependency only 
go as deep as a single class in core (and one in test).

I designed it this way in order to make Forrest2 as flexible as 
possible. For example, by rewriting that single class 
(org.apache.forrest.core.Controller) we can provide a version of Forrest 
that uses any other container and/or pipeline description language.

In other words, there is nothing stopping us having multiple 
controllers, one that uses my own style, one that uses an explicit 
pipeline language you define, another that uses XPipelines etc.

So, if you want to make a counter proposal which explicitly defines the 
pipelines, be my guest. Lets consider the advantages of each approach 
and then implement a third that is the killer offspring of the two.


View raw message