So with Jetspeed I wanted to be able to run it headless, ie without a Servlet engine. This is a requirement with Cocoon 2.0 and I wanted this to be in Jetspeed 1.0. I made one critical mistake though. I use RunData and DynamicURI in a lot of places. These two classes are highly servlet specific. However, the really don't need to be. So what I was thinking of is writing a TurbineRequest, TurbineResponse, TurbineSession and TurbineContext interface. The default implementation of these would just decorate the regular ServletRequest, ServletResponse, etc. What this would provide though is the ability to have headless RunData and DynamicURI. This would allow us to develop content that doesn't require a servlet engine. Why? If someone is writing a web app of medium complexity (very session intensive apps or post based apps would require work) could run this headless and maybe export their content from Turbine to static HTML. I want to do this with Jetspeed right now. I want to be able to build a sample site (right now for testing) and export it. In the future I want Jetspeed to have the ability to write a large section to static content and just redir to that instead. Nothing is faster with static content than Apache and I would like to leverage this. This would be a significant change. Similar to the package reorg that happened before. A non-trivial amount of code would have to be reworked. It isn't a perfect solution. It would be a hack similar to the Cocoon 1.x as an API hack where they have CocoonServletRequest, CocoonServletResponse, etc. But at least it would work for small exports. Ok... flame me :-) -- Kevin A Burton ([EMAIL PROTECTED]) http://relativity.yi.org Message to SUN: "Please Open Source Java!" "For evil to win is for good men to do nothing." ------------------------------------------------------------ To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Problems?: [EMAIL PROTECTED]
