Ross, thank you very much for this interesting and long answer. I really learned a lot of it, esspecially the difference between Web Framework and Publishing Framework in the case of Cocoon and Forrest.
> This would be requirements creep for Forrest. We are a content framework not > a web framework. Given that the goal of Forrest is to provide many output > formats from many input formats (and according to the PIWI website this goal > is shared) then I am struggling with the above affirmation. Now that I understand your goals fully for the first time, I also understand my faults in the past with forrest. I have to rewrite the goals of PIWI actually. I now consider PIWI a webframework. PIWI shall integrate several projects in a smooth way and shall provide many output formats from many input formats (as forrest does) too. We wrote the PIWI-Crawler in another svn folder. Means the PIWICrawler is totally seperated from the PIWI-Core. I may consider this more a publishing tool now. > Either you don't need to support forms, or you need to support them in a way > that is compatible with the goal of the project, i.e. give the best possible > rendering of a page given the constraints of the output format. Yes. We want to support forms as a web feature and the issue how to work with them when static content is beeing generated is still open and unresolved. > Exactly, see my comments above. I feel that either the PIWI objectives are > poorly stated on your website or you have a sever case of requirements creep > on your hands. Guilty in the case of poorly stated. I have to state out that PIWI is a web framework. And there is an existing tool called PIWI-Crawler which has publishing tool features. > Historically Cocoon... >... but Cocoon is most definitely a web framework. Thanks for that - I fully understand now. > Given the history of Forrest I doubt we would be interested in a project > that brings back the requirements creep that resulted in the creation of > Forrest in the first place. After reading your mail, i understand that you would say this is a step backwards :-) > a) decide what the scope of PIWI is and, if necessary address the > requirements creep issue > b) allow Forrest plugins to be reused without modification (a script for > conversion might work) > > Even then I'm not saying you will get traction, I'm only saying I doubt you > will get traction without that. I see. Well, since we actually want have this features you consider requirement creep, I think that PIWI actually doesn't fit perfectly to Forrest. Allowing Forrest Plugins to work would be horror to implement in PIWI I guess. Even a conversion script will be heavy work. I think this has to be developed in Java, not PHP. >> I see some synergies in PIWI and Forrest. For example, I always wanted >> to use Forrest but had no java host ready. > > But this shows the misunderstanding you have of Forrest. The idea is that > you host static content, not dynamic content. If you need dynamic content > you need a web framework not a publishing tool. To host static content you > don't need Java (or PHP) Yes. Thanks that statement enlightened me. > Sure, and your work has gone further than my Forrest 2 experiments did. > However, it has diverged from the goals of Forrest and is therefore, in its > current form, a very different project. Totally true. Sadly - I really was excited about bringing some benefit to forrest. Instead of that, I should better visit Cocoons mailinglist. However, I learned much and would like to thank you for your explainations. I will not bother this list again with my ideas of contributing PIWI as a sub project of Apache Forrest - I may find a Champion in a more appropriate project :-) Merry christmas + and good new year, Christian
