Raphael,
Thank you for summarizing the open issues.
We (IBM) certainly want to get our hands dirty with the customizer.
With regard to multi-threading issues, I think there is more than the
caching system that needs to audited.
Santiago removed the RunData from PortletConfig the other day, but there is
still stuff left in the PortletConfig
that definitely does not belong there. Stephan Hesmer is looking into that
right now.
Cheers,
Thomas
----- Original Message -----
From: "Raphael Luta" <[EMAIL PROTECTED]>
To: "JetSpeed" <[EMAIL PROTECTED]>
Sent: Thursday, November 09, 2000 16:55
Subject: [Proposal] Jetspeed 1.2 TODO list
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.
* 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].
* Provide a working customizer
At least a basic customizer (or customizer hook) should exist
for both portlets and the layout system.
* 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.
* 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.
* 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]
* 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]
--
--------------------------------------------------------------
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]
