"Schwarz, Marcus" wrote:
> > -----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.
> >
Release 1.2 is further apart than next beta, I understand.
>
> > * 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.
>
With regards to problem with the handling in the disk cache of external URIs, I
will work support for cacheable and noncacheable external URIs, instead of
"local" versus "remote", plus configuration support for fully dynamic URIs. So
concerns expressed by Ingo about this will be solved cleanly.
>
> > * 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.
>
If it uses and relies on current portlet rendering mechanism, you should commit
before we start working on multithreading issues, so that you will do less work
if we have to restructure the layout process (wrt ACL checking in runtime), and
we will have to check for multithreading problems only once.
>
> > * 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.
I think most of it is solved (The RunData issue). If we don't want to change the
APIs a lot, I could do remaining work (having a dynamic PortletContext and a
static PortletConfig) putting the dynamic parameters of the user PSML for a
portlet instance (the PortletContext) as RunData parameters or in the session.
This will clean the problem without having to change more the APIs, until we
have the final API.
We will have to look for other errors, but I'm pretty confident by know.
>
> >
> > * 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.
> >
Agreed. URLs without protocol should be taken as relative to the webapp, while
full URLs should be taken as absolute (external). We can even use things like
http://user:pass@site/collection/resource for authenticated access to resources.
I know it's a hack for now)
>
> > * 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 :-)
>
I will try to inspect it and see what is wrong.
Any volunteer for writing a FAQ? Preferably someone that has installed recently
from CVS.
>
> > * 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....
+1 also. If it works, don't touch it!
>
> > * 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.
Not so sure. The mechanism for caching Portlets in memory is taken directly from
Cocoon, and it impacts severely rendering performance. At least this dependency
should remain, unless this cache is already ported to Avalon, and then we should
migrate dependencies.
>
>
> > 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]
--
--------------------------------------------------------------
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]
