forrest2 and the future

[Tim Williams <wi...@gmail.com>]

Figured I'd start a new thread to give some comments/questions now
that I'm able to build it.

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.

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?

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.

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

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

Thanks again for providing some concrete basis for this discussion.
--tim

RE: forrest2 and the future

["Gav...." <br...@brightontown.com.au>]

Hi All,

> Tim Williams wrote:
> > First, great work on this.  

Agree,

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

This was my thinking too, I wasn't tough though, just that I could not
Base any kind of constructive feedback based on ideas alone, I needed
Code to look at. Now that we have some, hopefully more feedback will
Come of it. I like what I see so far and can sort of see where it 
Might be headed. My only feedback for the initial period I think will
Have to come in the form of testing and possibly patches. Until it has
Moved along a bit more I can not make judgment on direction or use of
One way of doing something as opposed to another unless it is really
Obvious to me. I am happy to let it find its own path for the time
Being.

..Snip.. 

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

Yes, concerns of many I think, after my initial look, excitement and play
With this new code I will shortly revert back to concentrate on what I
Can do to help with 0.8-dev and getting it released. I will still give
feedback on the new code where I can.

There is nothing to say that Forrest %day should not come back to help the
Process of closing Roadmap Issues. In fact I think it should come back for
This purpose.


Gav...

Re: forrest2 and the future

[Ross Gardler <rg...@apache.org>]

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">
  <sources>
    <source uri="helloWorld.xml" required="false" present="false"
            matchingpattern = "(.*)/(.*)\.xhtml2"/>
    <source uri="helloWorld.xhtml2" required="false" present="true"
            matchingpattern = "(.*)/(.*)\.xhtml2"/>
   </source>

   <inputPlugin id="xhtml2"/>

   <outputPlugin id="html"/>
</request>

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.

Ross