Re: [Proposal] Jetspeed 1.2 TODO list
"Kevin A. Burton" wrote: Raphael Luta [EMAIL PROTECTED] writes: snip Doesn't run. There's no tomcat in the CVS. In any case, it's only suitable for a generic introduction setup. Most people who will want to use jetspeed will need to reinstall it with different DBs, etc... and we ought to make this task as easy as possible. Yes... but this solves a number of problems: - - if you install Jetspeed... now you have a sample configuration which you can use to get your configuration working - - Allows us to skip messages from people who just want to setup jetspeed to see what it is like. It is not more like a product. IMO this should be the default packaging for 1.2 - - Unit Testing... The Unit testing bases on the tomcat-build. Tomcat is used as the testing webserver. There is no Tomcat is CVS because this wouldn't be a good idea... if you need tomcat just pull it down from Jakarta... snip I don't say tomcat-build serves no purpose, it is worthwhile to have something that runs out of the CVS without worries (and that means putting Tomcat in otherwise I don't see the point). But tomcat-build is a not a replacement for a real Jetspeed WAR that can be deployed in production servlet environments. With the EngineContext rework and the refactoring of the Cocoon interface, nearly all Jetspeed properties can now be expressed relative to the current servlet context so that should not pose great difficulties to distribute a WAR. -- 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://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: [Proposal] Jetspeed 1.2 TODO list
"Kevin A. Burton" wrote: Raphael Luta [EMAIL PROTECTED] writes: snip What use do we currently have for Cocoon 1 in the engine that can't be done by a simple XSL engine or a simple Java code ? snip I think cocoon has some major advantages over a simple XSL engine and some other java support: - XML+java integation in one single XML file - high grade of interactive Java- devellopment possible - so faster devellopment possible (in fact with cocoon you can devellop Java-Code as if you devellop interactive Javascript code: simply make your change and press the RELOAD-button: your changes show up immediatelly! no java-compiling - no jar-integration - no realod of the jetspeed engine etc...) - no loss of speed though caching of compiled XML+XSL+Java bytecode in cocoon (no repeated XML-parsing!) So I would be very happy to see continued cocoon support in the next jetspeed release. Johannes yeah. I am +1. I thought about it and I would rather see a cleaner design than a hack. Lets go for it. Kevin -- -- 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]
Re: [Proposal] Jetspeed 1.2 TODO list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Santiago Gala [EMAIL PROTECTED] writes: 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) yes... they probably will :).. no worries... I will try to get them in :) 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 :-) snip :) - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Cell: 408-910-6145 URL: http://relativity.yi.org Any programming language is at its best before it is implemented and used. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE6EezQAwM6xb2dfE0RAhscAJ9CNe5XEcKTiM+CdT6GV/T6Ry7hHQCgsp3b sLbvmFE9JhSFde0iC0rk0F0= =VbZe -END PGP SIGNATURE- nuclear domestic disruption strategic PLO Soviet South Africa Serbian Honduras munitions supercomputer Panama spy Nazi NSA Ortega -- -- 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]
Re: [Proposal] Jetspeed 1.2 TODO list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Raphael Luta [EMAIL PROTECTED] writes: snip That is already in there. I have said it a number of times but the tomcat-build will give you this :) Doesn't run. There's no tomcat in the CVS. In any case, it's only suitable for a generic introduction setup. Most people who will want to use jetspeed will need to reinstall it with different DBs, etc... and we ought to make this task as easy as possible. Yes... but this solves a number of problems: - - if you install Jetspeed... now you have a sample configuration which you can use to get your configuration working - - Allows us to skip messages from people who just want to setup jetspeed to see what it is like. It is not more like a product. IMO this should be the default packaging for 1.2 - - Unit Testing... The Unit testing bases on the tomcat-build. Tomcat is used as the testing webserver. There is no Tomcat is CVS because this wouldn't be a good idea... if you need tomcat just pull it down from Jakarta... snip 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 think removing Castor while definitely a good move is ambitious for a 1.2 release, but if you can commit a lot of time to fix this, go for it :) It might be something to branch. I don't know if I can continue with Castor... it is really bothering me :) snip What use do we currently have for Cocoon 1 in the engine that can't be done by a simple XSL engine or a simple Java code ? snip yeah. I am +1. I thought about it and I would rather see a cleaner design than a hack. Lets go for it. Kevin - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Cell: 408-910-6145 URL: http://relativity.yi.org Questions are the beginning of wisdom. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE6Ee3aAwM6xb2dfE0RApq+AJ0UE3bj+lI8vs0SJPt2M2tvRNEsQgCgvOEg Umh4VjpX6HyPkVj1oIci6UY= =NzDv -END PGP SIGNATURE- SEAL Team 6 munitions security $400 million in gold bullion Khaddafi Kennedy genetic kibo Uzi Ft. Meade radar Albanian Saddam Hussein Soviet smuggle -- -- 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]
Re: [Proposal] Jetspeed 1.2 TODO list
There is no Tomcat is CVS because this wouldn't be a good idea... if you need tomcat just pull it down from Jakarta... snip I don't agree with that. It makes it drop dead easy for someone to get up and running with Jetspeed. Given that the #1 complaint about Jetspeed is the fact that it sucks to configure, I think that your #1 goal should be to make it drop dead easy for newbies to get things working. -jon -- Scarab - Java Servlet Based - Open Source Bug/Issue Tracking System http://scarab.tigris.org/ -- -- 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]
Re: [Proposal] Jetspeed 1.2 TODO list
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]
Re: [Proposal] Jetspeed 1.2 TODO list
-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. 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 :) * 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 :( * 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. OK, enough for now. Let's do some real work... :( :) - -- 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]
Re: [Proposal] Jetspeed 1.2 TODO list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Stevens [EMAIL PROTECTED] writes: on 11/9/2000 7:55 AM, "Raphael Luta" [EMAIL PROTECTED] wrote: * 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]. I think that the ECS stuff should also be removed and replaced with either an entirely XML solution or Velocity should be used. *Anything* but ECS. * 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. Jetspeed should become a Turbine Developer Kit (TDK) application which is essentially a WAR + all the extra .jars and Tomcat. That is essentially what it is right now. tomcat-build - WAR. I haven't looked at the TDK stuff for a while so I will check :) You should take an instance of the TDK (ie: everything but the documentation) and check it into CVS. This will gain you a few things. #1. People can simply check Jetspeed out of CVS and have a fully configured and running application without having to do any installation work or edit properties files. tomcat-build again :) #2. It will remove the headache of having people sending "how do I set Jetspeed up" messages to the list. If I see one more of those, I'm going to scream. You guys don't even see how much private email I get asking ME how to configure Jetspeed...sigh. Delete. tomcat-build again :) I did this with Scarab and it has worked beautifully. I don't see any reason why you guys can't do it as well. snip It will check into it. I vote +1 to remove it and find something else. Also I vote +1 to switch to turbine's Peer model and use Torque to generate everything. snip no problem there... - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Cell: 408-910-6145 URL: http://relativity.yi.org Linux. The *only* Operating System you will ever need. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.2 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE6C4imAwM6xb2dfE0RAkW2AKDIaxIRUFO8ADyTw5lAV/jG7JRpXACeIza1 4kh89yeWnE2K7LNdVxE/CpY= =u2/V -END PGP SIGNATURE- kibo fissionable genetic Qaddafi CIA supercomputer strategic DES bomb colonel nuclear [Hello to all my fans in domestic surveillance] FBI South Africa Waco, Texas -- -- 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]
Re: [Proposal] Jetspeed 1.2 TODO list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Prickett [EMAIL PROTECTED] writes: snip +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. Well... a lot of this stuff should be made an Avalon component. Shortly I want to post a document which describes a set of refactorings that need to be done to make Jetspeed 2.0 cleaner. snip I can help with the WAR/Installation procedures but not right away... ug... already done... tomcat-build. :) * 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. yes... +1. Castor should go down in flames :) In previous releases of Castor the code generator was more reliable than the mapping alternative, but IMHO that is not the case now. yup. snip - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Cell: 408-910-6145 URL: http://relativity.yi.org The unconstitutional government for the corporation, by the corporation must be overthrown! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.2 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE6C4kzAwM6xb2dfE0RAko2AJ9pLvhqlaSU9XXf//c+quoE/H2lxwCcCpNf EdmbJ86TzwvFK03BEro+FVo= =xIx8 -END PGP SIGNATURE- bomb Qaddafi DES NSA Rule Psix Treasury ammunition nuclear class struggle South Africa NORAD Cocaine SDI Legion of Doom Serbian -- -- 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]
Re: [Proposal] Jetspeed 1.2 TODO list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Santiago Gala [EMAIL PROTECTED] writes: "Schwarz, Marcus" wrote: snip 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 snip how are you marking cacheable vs noncacheable??? Kevin - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Cell: 408-910-6145 URL: http://relativity.yi.org Life is good -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.2 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE6C4sVAwM6xb2dfE0RAvyoAKCvusAy8ks+lsy65jz49WR+jpVUhACfWI0Y VnIjHvWxjpxWvg0lWAh+tPw= =5lmK -END PGP SIGNATURE- AK-47 SDI colonel terrorist Clinton FSF Khaddafi South Africa Noriega plutonium Panama Waco, Texas nuclear supercomputer PLO -- -- 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]
Re: [Proposal] Jetspeed 1.2 TODO list
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)
Re: [Proposal] Jetspeed 1.2 TODO list
At 16:55 2000-11-09, you 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 * 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]. Yes, I will work on this. * Provide a working customizer At least a basic customizer (or customizer hook) should exist for both portlets and the layout system. +1 As Thomas already wrote, we'll also work on that. * 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. true. * 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. +1 Haven't spent any time on that yet - what are the rules for correctly marking up docs? * 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] Yes, concentrate on things that doesn't work first. * 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] ingo. -- -- 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]
Re: [Proposal] Jetspeed 1.2 TODO list
"Kevin A. Burton" wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Santiago Gala [EMAIL PROTECTED] writes: "Schwarz, Marcus" wrote: snip 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 snip how are you marking cacheable vs noncacheable??? Currently we are using the isLocal() call in DiskCacheUtils. It looks for virtual URIs (no protocol) and localhost URIs as local, and all else remote. The current strategy is that local things are not cached, but delivered directly through URLConnections, while remote entries are cached. My proposal is that we have a list of regexps in the configuration specifying non cacheable entries: - A given server is non cacheable. - Part of the space of a given server is non cacheable - All URIs with a given suffix are not cacheable - all .*/servlet/.* entries are not cacheable ... The internal marking will be done by having something like: ResourceStoreEntry is an interface, abstract representation of an external resource. It would support downcasting for common variants (in example isWritable() and getWritableResource() that would down cast it to a WritableResourceStoreEntry). HttpResourceStoreEntry is a concrete, non-cacheable representation for HTTP URIs. A subclass of this could implement the Writable interface (see down) through simple HTTP PUT. FileResourceStoreEntry is a concrete, non-cacheable representation for file URIs. It could implement the WritableResourceStoreEntry interface CacheableResourceStoreEntry is an abstract representation of a cacheable resource with semantics for expiration or refresh. WritableResourceStoreEntry is an abstract representation of a writable resource with a getWriter methods to handle character writing (beware i18n, all writing is better done as characters that as bytes). DAVWritableResourceStoreEntry is a concrete representation of a DAV resource that can be written using DAV ... This has not been implemented yet, but I think we should go into something similar to that for having the cache as something more abstract. All external resources in Jetspeed should use this abstraction, to enable other features like caching, maybe authentication or other similar checks, and to tackle with the problem of parallel download of the same resource by different threads. Now, all external resources use the DiskCacheEntry abstraction, but it is not as powerful and modular as the things we are envisioning for Jetspeed. I think such a service, when polished, should go into Avalon as a pluggable service for use in other projects or separate evolution and maintenance of the APIs. Do you know if some service along the lines, ideally with a transparent management of a hierarchy of caches (memory/disk) exists already? Kevin - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Cell: 408-910-6145 URL: http://relativity.yi.org Life is good -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.2 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE6C4sVAwM6xb2dfE0RAvyoAKCvusAy8ks+lsy65jz49WR+jpVUhACfWI0Y VnIjHvWxjpxWvg0lWAh+tPw= =5lmK -END PGP SIGNATURE- AK-47 SDI colonel terrorist Clinton FSF Khaddafi South Africa Noriega plutonium Panama Waco, Texas nuclear supercomputer PLO -- -- 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]
Re: [Proposal] Jetspeed 1.2 TODO list
ingo schuster wrote: * 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 Haven't spent any time on that yet - what are the rules for correctly marking up docs? The website is generated with stylebook. the xdocs directory contains the original documents, marked up is a simple DTD which is a kind of simplified DocBook markup. There's an Ant task in build.xml for generating the real site from these xdocs. -- 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://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: [Proposal] Jetspeed 1.2 TODO list
Santiago Gala wrote: Currently we are using the isLocal() call in DiskCacheUtils. It looks for virtual URIs (no protocol) and localhost URIs as local, and all else remote. The current strategy is that local things are not cached, but delivered directly through URLConnections, while remote entries are cached. My proposal is that we have a list of regexps in the configuration specifying non cacheable entries: - A given server is non cacheable. - Part of the space of a given server is non cacheable - All URIs with a given suffix are not cacheable - all .*/servlet/.* entries are not cacheable ... The internal marking will be done by having something like: ResourceStoreEntry is an interface, abstract representation of an external resource. It would support downcasting for common variants (in example isWritable() and getWritableResource() that would down cast it to a WritableResourceStoreEntry). HttpResourceStoreEntry is a concrete, non-cacheable representation for HTTP URIs. A subclass of this could implement the Writable interface (see down) through simple HTTP PUT. FileResourceStoreEntry is a concrete, non-cacheable representation for file URIs. It could implement the WritableResourceStoreEntry interface CacheableResourceStoreEntry is an abstract representation of a cacheable resource with semantics for expiration or refresh. WritableResourceStoreEntry is an abstract representation of a writable resource with a getWriter methods to handle character writing (beware i18n, all writing is better done as characters that as bytes). DAVWritableResourceStoreEntry is a concrete representation of a DAV resource that can be written using DAV ... This has not been implemented yet, but I think we should go into something similar to that for having the cache as something more abstract. All external resources in Jetspeed should use this abstraction, to enable other features like caching, maybe authentication or other similar checks, and to tackle with the problem of parallel download of the same resource by different threads. Now, all external resources use the DiskCacheEntry abstraction, but it is not as powerful and modular as the things we are envisioning for Jetspeed. What you need in a content management API which exposes some document manipulation functions (restrieve/store/update/properties/...) and implement different data source providers such as a syndication system. Such a system may have a notification feature for informing its clients that the data source has changed in the repository. In believe, most of this is already done by Prowler. For complex needs I think it's way easier to port the syndication to prowler and write a ProwlerPortlet than rewrite a complete Content Management system. -- 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://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
Re: [Proposal] Jetspeed 1.2 TODO list
"Thomas F. Boehme" wrote: 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. Yes it's true. PortletConfig contains contextual informations which have a different scope form either the request (it may persist between request), the user session (it may be shared by several sessions) or the portlet (it will change in the lifetime of the portlet). One proper way to do it: - subclass RunData in JetspeedRunData and add the contextual methods directly in this subclass or in a context object stored in RunData - when parsing the PSML store all the contexts in the PortletSets in a Hashtable using the Portlet object as a key. - in the PortletSet getContent() modify the RunData context before calling Portlet.getContent(). This require to take some precautions in the RunData modifications and may impose some change in the PortletControl API (which is the weakest part of the implementation anyway). I'll most likely have to do something like this for using templates but I'm not sure it's doable for a beta next week. -- 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://marc.theaimsgroup.com/?l=jetspeed Problems?: [EMAIL PROTECTED]
RE: [Proposal] Jetspeed 1.2 TODO list
-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 Problem
