> -----Original Message-----
> From: Raphael Luta [mailto:[EMAIL PROTECTED]]
> Sent: Donnerstag, 9. November 2000 07:56
> To: JetSpeed
> 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.
>
This componentization is really necessary. For people new to Jetspeed
it's not easy to understand the complete architecture and system-flow.
The reasons are clearly missing documentation (I will try to bring in
some high-level docu soon) and no clear seperation into functional
blocks.
Also we will make a proposal in the next time to bring in some functionality
for handling foreign content sources (cookies, URL-rewriting) to the core.
I'm sure we will have an interesting dicussion where this functionality
should resist.
> * 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].
>
we have an implementation of proposal 4, which enables to define
security-permissions on each portlet and parts of it's functionality (edit,
maximize, ...). This functionality is directly accessing Turbine's ACLs
to retrieve the permissions/roles of the current user. We will post
this stuff as soon as head has stabilized.
> * Provide a working customizer
> At least a basic customizer (or customizer hook) should exist
> for both portlets and the layout system.
>
that's really important. Without this functionality the use of Jetspeed
is dramatically decreased in "real" cases.
We have a small solution for this, but I'm not
sure if it's really fitting into the community's approach, because we
are using "external" parsers/creators and UI's to visualize and edit
the layouts. Also the possible functionality of PSML is reduced in some
areas, because we don't need it (e.g. we are just supporting 2/3 columns
and no complex nested structures). We will check, whether we can bring
back parts of it to open source.
> * 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.
>
I will post some new docs in the next weeks. But it will just cover
parts of the whole thing. But better as nothing :-)
> * 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]
>
+1. It works and we should focus on things, which are not working....
> * 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. seperation is always good. I also don't like the current hack.
> OK, enough for now. Let's do some real work... :(
>
Currently we have a high amount of internal stuff to do and will
focus on "our" areas with full power starting in 3-4 weeks.
Sorry for this delay :-(
> --
> 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://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
