Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 74993 invoked by uid 500); 12 Apr 2001 07:07:01 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 74973 invoked from network); 12 Apr 2001 07:06:58 -0000 From: "Carsten Ziegeler" To: "Cocoon-Dev@Xml. Apache. Org" Subject: [C2]: ToDo - List for going Beta Date: Thu, 12 Apr 2001 09:06:53 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release 5.0.5 |September 22, 2000) at 12.04.2001 09:06:53, Serialize by Router on PBSN1/Systeme und Netzwerke(Release 5.0.5 |September 22, 2000) at 12.04.2001 09:06:53, Serialize complete at 12.04.2001 09:06:53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Hi, in addition to the current ToDo-List I would like to discuss the = following points which I find important for the beta. I think we should very = quickly agree on this points, if they are useful or if they are just overkill, = so that we can implement them in the next week or leave them for another = release. Most of them have been discussed in the last weeks, but we haven't had = any final result for them. 1. Creating wrappers for Session and Cookie The creation of these wrapper classes would allow us to be = independent of the javax.servlet classes. As discussed earlier this week this is very useful. If we agree on this, I will volunteer for it. 2. Cleaning up the environment We had the recent discussion about the sendRedirect() method of the Response object (same applies to the getRealPath() of the Context). The discussion about sendRedirect() showed, that most of us agreed to remove it from the Request object. But the main problem then would be porting existing applications from C1 to C2. If we leave sendRedirect() only for porting reasion, everybody will use it, and we have no chance to remove it at a later time. My suggestion is to remove the sendRedirect() from the Request. For=20 porting reasion the HttpRequest still contains the sendRedirect(), thus casting the Request to the HttpRequest will allow the call the method. This will only work in the http environment, but for me=20 this sounds reasonable for a fast migration. There are others methods in the environment which should be removed for same reasons as the sendRedirect(). If we agree on this, I will volunteer for it. 3. Synchron sitemap reloading As I explained earlier this week, the asynchron reloading of the sitemap is a nice feature but not suitable for development. I would suggest adding a configuration parameter for cocoon to specify if the reloding is asynchron or synchron. If we agree on this, I will volunteer for it. 4. ErrorNotifier The "error-pipeline" has a fixed ErrorNotifier. This is not = customizable like the other components in the sitemap. For an easier error = handling I would suggest a pluggable system. There a two easy possibilities: a) Configuration of all ErrorNotifiers like all other components, = e.g. the generators. This would lead to a configuration part: and then =20 =20 b) The ErrorNotifier currently used is the default and it is possible to specify another class with the handle-errors tag: =20 =20 If we agree on this, I will volunteer for it. 5. Reloading of jar-files The class-path for the Cocoon-Servlet is only build once when the = servlet is initialised. If you want to deploy other jar files you have to = restart the servlet. A reloading of the Cocoon is not sufficient. This is not very convenient. Suggestion: When Cocoon is reloaded (a new cocoon = instance is created then) the classpath is rebuild and used. 6. Caching of StreamPipelines The current caching algorithm caches only the event pipeline. For FOP = it would be very nice to cache the whole response. I would like to extend the caching algorithm, to specify the = Cacheable interface even for Serializers and make a test implementation for the = FOPSerializer. I think this is a nice to have but not required. But if I have enough time I would like to test this. So I think we should quickly discuss this, add the remaining points to the ToDo-List, search volunteers (if not already found...) and implement = them asap as the 1st of may is approaching. If you have any other points for the ToDo, comments, etc. please let us=20 discuss them now. Carsten=20 Open Source Group sunShine - b:Integrated =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn www.sundn.de mailto: cziegeler@sundn.de=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org