On Thu, 9 Nov 2000, Raphael Luta 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 - I think once we "untangle" things a bit more we will find that we can
actually create something with a lot more power and flexibility. For
example we could use the OCS syndication business objects for a
syndication crawler that you could run at the command line.
> * 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].
>
Good...
> * 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.
>
I can help with the WAR/Installation procedures but not right away...
>
> * 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 think we should rethink throwing out Castor in the next release. You
dont have to use the code generator to generate code. You can use a map
file to generate XML. This seems to actually work better with current
releases of Castor.
In previous releases of Castor the code generator was more reliable than
the mapping alternative, but IMHO that is not the case now.
> * 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]
>
+1 on that. I use Xalan directly in the iCalendar code.
> 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]
>
>
Jeff Prickett
[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]
