On Sat, 3 Nov 2001, Stefano Mazzocchi wrote: > [sorry for crossposting, but this interests both communities, I think]
I believe so, too, so I maintained the crossposting. > One question: you want to remove the connection overhead in order to > obtain Cocoon services and I agree that this is a "good thing"(tm). Not only the connection overhead, but also the Sitemap overhead, the Cocoon pipelining overhead etc. - it's not only a question of speed, but also one of usability. > Originally, Pier and I designed Cocoon2 to be an avalon block but > decided to move away from that since the APIs weren't solid enough. Fair enough. > Now, this said, please reread the above sentence: the key part is > "obtain cocoon services". > > Cocoon is, like it or not, based on a request/response paradigm that is > modelled after HTTP. What is the philosophy behind that model? Why tie Cocoon to a specific delivery method, even though only philosophically? Shouldn't there be a more generic API with HTTP-like request/response being just one of several wrappers? > So, my vision is that if you want "XML --> XSL(T|FO)" processing block, > you are going to create a behavioral interface that doesn't ask for a > particular Cocoon resource, but pushes the various streams into the > service and wants to obtain a result. Yes, I am very open as to the exact API, but I think it should be simpler than having to install a whole Cocoon pipeline and push my request over HTTP. 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. > I simply do not and for the reason above: IoC means that you ask for a > resource to Cocoon and it knows what to do. > > This is a design pattern that must not be altered in any way, under any > circumstance or Cocoon will be nothing different from > Xerces+Xalan+FOP+Batik. You call it a design pattern, but 10 years ago such a system was called a monolithic black-box. Of course every system is a monolithic black-box at some point, if you go deep enough. But then every system is also IoC and it is arbitrary where you define the legal entry-points to be. I think "Xerces+Xalan+FOP+Batik" is not Cocoon. These are seperate projects and every Apache project can use them as they see fit. But I think it would be good, if the various projects could agree on interfaces. But this interface cannot be Cocoon, because it assumes too much. For me Cocoon is the Sitemap, XSP, generators, serializers etc. - of those I would only like to steal XSP, because code generation may be useful in other places as well. > I hope you guys understand my strong feelings about IoC. Is there any "mission statement" or white paper that explains exactly what IoC is and why Cocoon uses it? Perhaps I misunderstood it, but to me it looks like some arbitrarily defined interfaces and everything below is a black box. > If not so, please, make yourself heard because it's vital that we all > agree on something so basic. If I remember correctly, in the ca. 2 years I've been involved with Cocoon and recently Avalon I haven't managed to persuade anyone of anything. Actually, much of what I said one year ago wouldn't persuade me today, either. So, chances are I'm in the minority again with my opinion :) cheers, Ulrich -- Ulrich Mayring DENIC eG, Softwareentwicklung --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
