On Mon, 5 Nov 2001, Stefano Mazzocchi wrote: > Let's take Cocoon 2.0. Let's remove the "connection overhead", then the > "sitemap overhead", than the "cocoon pipelining overhead". > > What the hell do you end up having?
Cocoon would remain what it is, it might be distributed as a .sar application instead of a .war application. The functionality would be 100% the same - with the exception that some people (like me ;-) could do *more* with Cocoon, e.g. use it in a world that is not made up of a request/response pattern. I am not talking about Cocoon's functionality, just its internal structure, so the product would remain the same. > You what to remove the Servlet API interface, than the sitemap, than the > pipeline. So, what you want to do: assemble the pipeline components by > hands and run them? should this be called Cocoon? No matter what we call it, but it would be more than Cocoon does now :) > > > Cocoon is, like it or not, based on a request/response paradigm that is > > > modelled after HTTP. > > > > What is the philosophy behind that model? > > The philosophy is that this is what I needed when I started the project > and then found thousands of people that had the same need and joined the > ride (you as well). Yeah, I didn't mean the Cocoon1 philosophy, that product has been abandoned. I thought maybe this request/response pattern was re-thought for Cocoon2 as were so many parts of Cocoon1. > Cocoon is not bound to any delivery method. It's bound to the a very > general request/response mechanism and even has an pluggable enviornment > and object model that was abstracted over HTTP. Ok. > > Shouldn't there be a > > more generic API with HTTP-like request/response being just one of several > > wrappers? > > for example? For example queue-based systems. Maybe some people would like to use a JMQ-like system. Or rules-based systems. Maybe I'm getting carried away here. Need more think :) > > It is probably not very hard to write an Avalon block that does > > XML-->XSL(T|FO) - I think most of the code can actually be stolen from > > Cocoon and we just need some Avalon wrappers. So I can do that by myself > > if the Cocoon project thinks it's a bad idea. > > What I don't understand is what you want to achieve that some 20 lines > of glue code around JAXP 1.1 wouldn't already achieve. For my program it does not make a difference which way I do it. I just thought that maybe there are several people out there and we all could agree on a common format. This common format might become a factor, if Cocoon used it as well. That's all. > > Is there any "mission statement" or white paper that explains exactly what > > IoC is and why Cocoon uses it? > > what the heck is a "mission statement" on a open source project? Well, some kind of a text. A white paper, a design document, whatever you like to call it. > > Perhaps I misunderstood it, but to me it > > looks like some arbitrarily defined interfaces and everything below is a > > black box. > > If this is your vision, there is very little I can do about it. Well, you could tell me why the interfaces are not arbitrary and why everything below is not a black box :) > You'd like to use some of the internal Cocoon functionality in a > procedural way (you call the API), while Cocoon is a declarative > framework (it calls your code to do stuff). > > Those are opposite directions and cannot work together. IIRC we had some very heated discussions about that in Cocoon1 times as well. Constantly people would come and ask "how can I call Cocoon from my servlet/EJB/whatever". And the response always was: "Convert your servlet/EJB/whatever to an XSP taglib and let Cocoon call your functionality." Apparently we're running into the same old problem here: you can use Cocoon, but if you use it, you must commit to it. Throw your other stuff away. I love Cocoon. There are some things that can be done extremely well with Cocoon. But in-between Cocoon1 and Cocoon2 I grew suspicious of that commitment. I still think the Sitemap is too proprietary a concept. I'm not saying that to criticize Cocoon, just to explain where I'm coming from in my thinking. Actually, I'm saying all that evil stuff in order to help the Cocoon project :) > But, please, understand that if you want to take Cocoon and cut it in > pieces just because you need part of it for your own stuff, well, do it, > but don't call it Cocoon because it would not be anymore. Destruction is not negative, you must destroy to build. Quick, who said it? :) Seriously, have a look at this fictitious history of a web application developer (the timeline is very arbitrary): 1993: Wow, that WWW sure looks cool. I'll write some HTML pages right away. My boss won't understand, but one day I'll be the star of the company. 1994: Hmm... need something to convince the boss. Let me put that cute page counter in. A small CGI/Perl script, no problem. Maybe I can hook up the coffee machine. 1995: We sure have a lot of HTML pages and I can't get any work done, because I'm constantly updating them. Whoever said the Web is for our marketing department to publish their blurbs??? I need to write some kind of generator that makes the HTML pages for me. Especially the navigation bar, it's the same thing on every page anyway. Another Perl script, this one a bit larger. 1996: Ok, the boss finally gets it. Now he wants all kinds of functionality on the web pages. More Perl scripts. What do they mean with "relaunch"? Oh my God, they're bringing in a designer, how am I going to teach that guy Perl?? 1997: A web shop?? Are you crazy??? This has got to stop. We need some common platform for our web functionality and it must integrate with our backend systems. Let's do Java on the backend and use servlets for the frontend. SSI is good for including the navigation bar. 1998: That Java stuff sure is cool. But it sucks to have so many servlets and each of them needs to write out HTML. We've put much of our HTML pages into servlets. Where are my icons?? Chaos! 1999: Man, this Cocoon is the total package. I'll get my HTML transformed into XML (which is way cool) and out of the servlets and back into the filesystem, where it belongs. Plus I can call real Java code from the XML pages, and what's more, I can wrap it in XML taglibs. Life is so good to me. 2000: Ok... the Cocoon frontends are nice, but they do too much.. the XSP pages don't really look like content, they look like logic in an XML wrapper. I have to put much of that logic into the backend, where it belongs and can be maintained independently from the frontend. My colleagues don't know Cocoon, but they do know Java. And I have to finally find a sensible platform for all our backend programs. 2001: Yeah, Avalon rocks, it can run all our backend programs as blocks. Wish they would release the goddamn framework. But our backend is in great shape, everyone can maintain it, we basically accept the Avalon wrappers around our classes and just code away. Now it's time to look at the frontend again. And what do you know? There's a whole new Cocoon out there and it is built on top of Avalon. I'm in paradise - I'll just grab that .sar application, throw it into the Phoenix apps directory and all our backend blocks can instantly talk to Cocoon. Seamless integration of frontend and backend - this is so good, I think I'm going to get drunk right away. Well... some parts of this story are more fictitious than others! ;-) cheers, Ulrich -- Ulrich Mayring DENIC eG, Softwareentwicklung --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
