cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [OT] cocoon is like windows
Date Fri, 01 Nov 2002 15:36:46 GMT
Recently I've been wondering whether Cocoon is getting too complex. I've got
an interesting reply from Stefano. I've been thinking about it unconciously
for a couple of weeks. 

So, I came to a conclusion that what Cocoon's documentation lacks is an
ideological or conceptual papers. There's a lot of information in mailing
lists, but it's mostly technical: how to do this or that. Less often and
scattered is info on 'why' you do this and that in some particular way. It's
like to tell that a car has 4 weels, but not to tell why it has them, why
there are 4 of them. So, when a guy downloads Cocoon, runs samples, he ends
up with a question: how to use it?

The issue is how to build a system? How to integrate Cocoon with the rest of
the infrastructure? What tasks are well suited for Cocoon? What kind of
systems are not fit for Cocoon? 

Maybe there's a need in documents with 'reference architecture'. It would
tell the manager or architect, how you, Cocoon developers, envision your
product co-existing and collaborating with other systems. 

Ok, that's the end of first part. Here comes the second.
So, what's Cocoon? What paradigm lies beneath it? 

I see it this way: it's a Web GUI to a collection of components, which can
interact with each other in the pipelines. That's how it's seen from the
user's point of view. There's a bunch of generators, transformers etc. If
you want to do something with cocoon, you have to run some components.

I stressed Web GUI because, you hide your components from the uers behind
the Web interface. You configure the sitemap, then the only way to get
Cocoon do something is to enter URL in the browser launching one of the
pipelines. The user can't access the Cocoon components in his own way. He
doesn't even know about their existence. In other words he can't dynamically
form a pipeline.

I see an analogy with Unix. 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.

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: 
This will be my command line to launch a generator then forward it to a
Or like this:
This would store the output in the temporary URL: /temp/a, so it can be used
instead of the generator later on.

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).

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."

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

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

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

View raw message