Hi, Kevin. Nice to see you back!
I hope the switching of branches that I did does not break your code. If you have
uncommited changes you should save diffs and apply them in the new branch
(proposal-0003-work-01)
I hope also that we have not broken many things. We are getting to speed, and that
means that from time to time we step on other people's feet, as I learned in my Tango
classes :-)
"Kevin A. Burton" wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Raphael Luta <[EMAIL PROTECTED]> writes:
>
> > 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.
>
> ah... yes. I think they don't qualify as being part of the 'engine' though.
> These should be moved to /modules.
>
> > * 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
>
> hhm... +0 on putting Turbine ACLs in the registry... don't know.
>
> > [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.
>
> This still needs to be addressed.
>
> > * 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.
>
> I don't think so... there was only one small issue that need to be worked out.
> That should be in TODO.
>
I agree. We should coordinate the small issues. I will post my current view on the
remaining issues and a proposal for solving it when we have studied it in depth.
>
> > 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.
>
> That is already in there. I have said it a number of times but the tomcat-build
> will give you this :)
>
I never tested it, but I thing we should test and document it in the release.
>
> > * 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
>
> > * 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]
>
> I was going to take this up. I would say that personally the Castor stuff is
> the worst part of Jetspeed right now. It really scares me :(
>
I saw that you have worked on it in the old HEAD. I'm +1 if it does not break CVS
code, so that we can parallelize development.
>
> > * 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 would rather redesign it..
>
> > [I'd vote for moving the CocoonPortlet and Cocoon support to a
> > modules directory and remove any dependency of the engine on
> > Cocoon 1]
>
> Then we would have to drop Cocoon 100%. The Engine is already hacked to support
> Cocoon 1.x. If we want to clean it up then we have to drop Cocoon which would
> make a lot of people angry (myself included). If we decide to do this then we
> need to go with Jetspeed 2.0 -> Cocoon 2.0.
>
I would also keep Cocoon in. I pointed out that the memory cache is taken from Cocoon
right now (am I wrong?). We could try to redesign the bridge better than drop it
completely.
>
> > OK, enough for now. Let's do some real work... :(
>
> :)
>
Do you feel that you will have more time from now on?
It was a real pity not to have you in London :(
>
> - --
> Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
> Cell: 408-910-6145 URL: http://relativity.yi.org
>
> proprietary == evil
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.2 (GNU/Linux)
> Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
>
> iD8DBQE6C4g2AwM6xb2dfE0RAjTSAJ9VERkdgQ6vdvlAn9bXEme49KStBgCgzxRj
> cluicsVIgp4HiAGmM9V+9Jg=
> =4sGL
> -----END PGP SIGNATURE-----
>
> munitions North Korea jihad Albanian Clinton strategic spy nuclear kibo
> assassination Kennedy smuggle South Africa NORAD BATF
>
> --
> --------------------------------------------------------------
> 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]
--
--------------------------------------------------------------
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]
