At 16:55 2000-11-09, you wrote:
>This a quick list of issues I think should be resolved before
>releasing 1.2. I've put some names behind some tasks because these
>people expressed their intention to implement the feature.
>
>* Componentization of the system
>Currently Jetspeed is both a portal layout system and a simple
>OCS syndication system. I think we should better separate both
>functionalities so that each can be run separately. Also
>we have also devleopped some nice portlets (such as JCM or Poll)
>which should be moved out of the engine, both to show that their
>use is optional and to give tham a better visibility.
+1
>* Turbine support
>Jetspeed is really a Turbine application and yet has not followed
>Turbine progress in the recent months.
>Several items may be tackled :
>- allow the use of templates with PSML elements
>- integrate Turbine ACLs in registry
>
>[I've already started the work on using templates in Jetspeed
>and Marcus Schwartz and Ingo Schuster are willing to work on
>the user/ACL stuff].
Yes, I will work on this.
>* Provide a working customizer
>At least a basic customizer (or customizer hook) should exist
>for both portlets and the layout system.
+1 As Thomas already wrote, we'll also work on that.
>* Fix multi-threaded operation / caching rework
>Make sure that the engine may be safely used in a multi-threaded,
>multi-user environment. If we want to avoid a major API change
>for the 1.2 release, this may require to disable or rework portlet
>caching.
>In any case, the caching system needs an audit to identify
>its shortcomings.
true.
>* Create a WAR
>We should be able to provide Jetspeed as a WAR application. This
>may require to change the way some properties are used so that
>all properties URL or files can be considered relative to the
>webapp root.
>
>* Update documentation
>A lot of documentation has been contributed to the mailing-list
>but usually it's not correctly marked-up. Someone should review
>all the existing docs to make sure it's up to date and maybe
>markup new docs for installation/development support.
+1 Haven't spent any time on that yet - what are the rules for correctly
marking up docs?
>* Castor support
>Some time ago, it was decided to drop Castor support and provide
>another XML <-> Java mechanism. This would imply a lot
>of factory rework.
>
>[I'd stick with Castor for 1.2 and remove it for the later
>releases]
Yes, concentrate on things that doesn't work first.
>* Cocoon support
>The Cocoon support provided by Jetspeed is currently a hack and
>I don't think it works with Cocoon 1.8, so we either need to
>drop this feature and use a simple XSL processor or re-design
>a Cocoon bridge.
>
>[I'd vote for moving the CocoonPortlet and Cocoon support to a
> modules directory and remove any dependency of the engine on
> Cocoon 1]
>
>OK, enough for now. Let's do some real work... :(
>
>--
>Raphaël Luta - [EMAIL PROTECTED]
>
>
>--
>--------------------------------------------------------------
>Please read the FAQ! <http://java.apache.org/faq/>
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Archives and Other: <http://java.apache.org/main/mail.html>
>Problems?: [EMAIL PROTECTED]
ingo.
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
