From cocoon-dev-return-30021-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Mon Aug 05 07:38:12 2002 Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 4934 invoked by uid 500); 5 Aug 2002 07:38:10 -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 4923 invoked from network); 5 Aug 2002 07:38:09 -0000 From: "Carsten Ziegeler" To: Subject: RE: [Proposal] Cocoon Organization Date: Mon, 5 Aug 2002 09:41:15 +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.2911.0) In-Reply-To: <002001c23895$ff7a6890$ac00a8c0@Gabriel> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 05.08.2002 09:38:09, Serialize by Router on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 05.08.2002 09:38:11, Serialize complete at 05.08.2002 09:38:11 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi everyone, I also thought about this problem in the last weeks (during some mountain climbing...) - does anyone remember Stefano's email about the "thermal death"? If not, search the archive and read it. Yes, Berin is absolutely right - Cocoon is way too big. And it's getting bigger and bigger. For usual web applications I guess you always only need let's say 20% of Cocoon - it's not always the same parts you need but you will never need everything of Cocoon at once (ok, never say never, I know). When we made our donation for the authentication and the portal framework, I tried to separate them as much as possible. You can build and use Cocoon without them and later additionally plug them in. (At least this is the way it should work ;) ) For other "parts" like FOP serialization etc this is also possible. But what for some "more core areas" like flowmaps or input modules? And I fear there are other things which only (currently) a minority really needs (and yes, add the authentication and portal frameworks to this list). In the last months the answer to this problem was always: blocks! So making Cocoon (just) one step complexer makes it more handable and easier to understand...really? If you look at the problems the average user of Cocoon has, then you see that most of them have problems understanding the complexity of Cocoon and getting simply started. IMHO this can't be solved by just adding another complexity layer. (This is not a -1 vote for blocks). Let's have a look at what had happened over the last weeks/months: several individuals added more and more features, like the authentication framework, the portal framework, the form handling, the flow maps etc. Each individual did not really care about the community, he only wanted to get this cool feature working. And don't get me wrong, this includes myself. We also started the "documentation project" and we "fought" with others who claimed about the poor documentation and Cocoon being too complex. In addition we are getting more and more RTs, patches and bug reports which all get more or less lost (or again simply add more complexity). So currently I see us as a very motivated group of individuals all doing their job (very good by the way) but not considering to act on a more community base. For example - to not offend others, I take myself as an example - the portal framework: In order to get it nicely working with some very cool portal/configuration features, I needed some other new features besides the portal framework in Cocoon. This includes the RequestLifecycle, the ConfigurableSitemapComponents and some other minor things. Who of you knows what these concepts are? Did I ask someone, if this really makes sense? Are they documented well? etc. Now I think we really did some mistakes (and yes, this again includes myself). To proof this, here are some questions (and please, they are not meant to be answered): - Who of the Cocoon community knows how the portal framework works? - Who of the Cocoon community knows how the authentication framework works? - What's the status in form handling? - Do we need input modules? - Do we have memory leaks? - Is the caching really working? - Does Cocoon work with JDK 1.4? - What has to be done for the next release, 2.0.4 or 2.1? But the most important question is: who needs all these new features? Shouldn't we focus on getting a even more stable release and more documentation instead? Who needs a portal framework inside Cocoon, who needs input modules and who needs blocks? Let's take the blocks concept as another example. We have the really great RT from Stefano and Giacomo, but look how many have responded to it. Do they not care about blocks? Couldn't they follow the RT? Are blocks really necessary? I personally didn't answer the blocks RT, because I feel that it is not the concept I (= Individual!) was looking for, but I can't express how it could be better. Or flowmaps? What is their use? If I didn't understand the sitemap, how will I ever learn about flowmaps? Ok, I know, one answer to this will be, if you don't want to use blocks or flowmaps, you don't have to. But how does this work? Will we state: "Cocoon has the sitemap, flowmaps and blocks. But don't worry, if this is too complex for you, just use only the sitemap and forget about the others, you don't need them...". Well... Many users already claim, Cocoon is too complex. And we say: it will get easier, because we add more cool features, like a portal framework, flowmaps and blocks to it! Now, I don't believe this and I fear the usual user will not believe this, too. Stefano already pointed at this in his thread about the "termal death of Cocoon." When he wrote that, I thought, "hmm, perhaps he's right - perhaps not, ah wait, how can I get this authentication thing working, hm, let's see..." - Now I know, he is right - if we go on following this road, I promise, we will have a termal death of Cocoon more sooner than later. And I think, the current blocks discussion does not help in this aspect. So what can we do about it? Try to act more like a team and let's more listening to the user needs. The documentation effort is one step in this direction, but personally I think there is a problem there, too. New documentation features are currently delayed until forrest is ready! So, instead of focusing on the real problem, a new construction area has been build up (forrest) which has to be completed beforehand! This is not very helpfull. But let's come back, to what we can do. First of all, a feature stop! I don't mean an RT stop. Second, thinking of SoC (ok, perhaps not the right context to use this term) - we should try to build a minimal Cocoon or core Cocoon if you prefer and put everything else into additional modules (read: not blocks). By modules I simply mean different directories in the CVS in order to optionally build them. Let's remove the authentication framework from the core, the form handling, the input modules, the flow map, the fop serializer etc - simply everything which is not necessary to run Cocoon. Third, let's identify the issues for the upcomming releases. Fourth, let's search for volunteers for the open issues, for bug fixing and for testing! Fifth, discuss the available patches and open RTs and make proposal documents out of them. Or putting it in other words: Let's not forget the users needs over all this cool new features and RTs. Now, I'm pretty sure, that some might now stand up and say: "Hey, Carsten, you know what? Cocoon is open source, so if you see a need, you can contribute and fix it." Well, that's the individual approach we were following in the last months. And does it really work? Or someone will say "Hey, it's alpha, what do you expect?"... And one final note: Just do a simple performance test: create a pipeline reading an xml file transform this in two steps with two xslt transformers and serialize it to html (or xml if you want). Do a stress test on the same machine using Cocoon 2.0, 2.0.1, 2.0.2, 2.0.3 and 2.1-dev. (I don't know the answer to this test, but I would bet a book on the result). So, whew, you see I had some time to prepare this email...and now the flame-war can begin... But summarizing this: +1 on Berins idea. Carsten Berin Loritsch wrote: > > > Currently Cocoon is 1.5 MB in size. That is a huge jar. In Cocoon > there > are the core files, the servlet compatibility files, the CLI > compatibility > files, and hundreds of components. > > The fact that we as a community are thriving is excellent. However, as > a > project, Cocoon is feeling quite heavy. Esp. since there are features > in > Cocoon that not everyone needs. I proposed this a while back, but I am > going to propose it again. > > We should split Cocoon into core development and component development > efforts, much like Avalon does with Framework and Excalibur. That will > allow the components to be packaged in jars that serve a similar > purpose. > Things like all the database related components should be in their own > mini-project. Each mini-project has its own documentation, and its own > life. It also allows each mini-project to determine whether it is ready > for prime-time or not. At every release, the core cocoon does not have > to worry about which components it has to move into scratchpad. Also > each set of components has a little focused mini-community so the docs > get upgraded in a focused manner. > > I have already seen the benefits of how this works in Excalibur--now > that > we are going through systematically. > > When I am generating a site, I don't want to have to include the portal > components or the DB and auth components. Those don't need to be there > for the site. > > Keep in mind that the mini-projects are all part of the cocoon umbrella, > and they foster functioning communities within the larger Cocoon > community, > not detract from it. > > > "They that give up essential liberty to obtain a little temporary safety > deserve neither liberty nor safety." > - Benjamin Franklin > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org > For additional commands, email: cocoon-dev-help@xml.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org