cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [OT] cocoon is like windows
Date Fri, 01 Nov 2002 19:40:55 GMT wrote:

> So, what's Cocoon? What paradigm lies beneath it?

I've used these two analogies to explain what Cocoon is, depending on 
what the person want to use Cocoon for (most of the time, I end up using 
both because it's hard to differentiate):

  1) for people using Cocoon for system integration, I call it a 
"software glue for the web". It is a framework that 'glues' together 
many different systems by adapting them on a common XML layer.

  2) for people using Cocoon for web development, I call it "web lego" 
(since component-oriented programming sounds too technical and many 
don't see the difference between COP and OOP). The notion is: Cocoon is 
like Lego: we design the shapes of the components and how they can work 
together, then you can use the ones we ship in our box, or write your 
own. The examples, provides suggestions on how to use the software, just 
like any lego box comes with instructions on how to do something.

> I see it this way: it's a Web GUI to a collection of components

:-) Cocoon is used extensively in pure B2B applications, expecially in 
banking environments. Where is the GUI on that?

> I see an analogy with Unix. 

Sure, both Cocoon and Unix use the same design pattern.

> One of its stregthes is that it has many
> utilities which can cooperate with each other. Cocoon is somewhat 
> similar in
> that. The difference is that in Unix any user can write his own 
> scripts, in
> Cocoon he can't. So, Cocoon in this sense is Windows: run your app and 
> don't
> bother with customizing the system for your needs.

Sorry, but that's very lame argument. In unix if you define your 
pipelines in a purely declarative fashion, that's due to the nature of 
use of Unix.

In Cocoon, you use a declarative syntax because the control is inverted 
(the client asks the server). And today, with the flowscript, you can 
decouple the flow logic (inherently procedural, so scripted) from the 
resource production logic (inherently declarative, so defined in markup)

> Here's the idea: why not to allow bypass Web GUI in Cocoon. Maybe 
> sitemap must be gone too. So, there must be means to build a Cocoon 
> powered system
> in such a way, that I can see what components are in Cocoon and use them
> deliberately. Suppose, I launch URL: /generators/dir and get the list of
> generators. Then I say:
> /generators/xsp/bla-bla@/serializer/html/ya-da-da
> This will be my command line to launch a generator then forward it to a
> serializer.
> Or like this:
> /generators/xsp/bla-bla@/temp/a
> This would store the output in the temporary URL: /temp/a, so it can 
> be used
> instead of the generator later on.

A cocoon console? that's wild :)

> Then I write my own scripts with things like that, and get my own pipeline
> installed for me. Maybe it's added to my personal sitemap for the current
> session, or forever (with cookies).

I really don't

> This way you tell the user: "this Web site is not your ordinary site. Here
> we provide you with the powerfull XML/XSLT toolkit, which you can use 
> as you
> like. Pick up your tools, make pipelines, save results in temporary URLs,
> access them later and so on. Customize it, use my site to analyze and
> process your data with my XML tools."

do you work for microsoft? :) it sounds like the kind of very stupid 
ideas people at microsoft get and turn an operating system into a 
humangous security hole.

> So, Cocoon will be more like Unix, and less like Windows, i.e. like OS 
> X :)

No, it would be much less Unix and more Windows, at least from a 
security perspective.

> have a good weekend and don't take me too serious :)

Nah, I'm already used not to take seriously architectural choices driven 
by parallel analysis of systems, instead of looking at what they were 
written to accomplish.

Next time, instead of performing differential analysis on two systems 
that do totally different things and propose the changes according to 
lack of parallelism, come up with some use-case scenarios and build from 
there. You are attacking the problem coming from the opposite direction 
and this leads to *serious* architectural mistakes (ask around at 
Redmond, I think they understood this by now :)

Stefano Mazzocchi                               <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message