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
