cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <u...@denic.de>
Subject One face to the customer
Date Fri, 13 Oct 2000 10:41:22 GMT
Today I want to ask a simple question: what is cocoon?

Let me propose an answer to this question by first saying what cocoon is
not. It is not an application in the sense that a user starts it on
demand and works interactively with it like a word processor or
spreadsheet. It is not a daemon that runs in the background and performs
tasks only at certain times like cron.

In my eyes it has a bit of both and should be characterized as a
service. It reacts to HTTP requests within a certain domain like *.xml.
These HTTP requests can come from an interactive application like a
web-browser. But they can also come from another service or a daemon.
The philosophy of "one face to the customer" means that cocoon should
provide a single, uniform interface to the outside world.

This interface should define an input pipeline and an output pipeline.
Applications, services and daemons can put things in the input pipeline,
cocoon puts the result in the output pipeline. cocoon doesn't manage
input and output pipelines, it doesn't care who puts things in it or who
takes things out of it. For example an interactive application (like an
XML Editor) may generate an XML file and put it in the input pipeline.
cocoon generates a PDF and puts it in the output pipeline. A daemon
looks in the output pipeline at certain times, retrieves the PDFs and
prints them out. Other programs may use cocoon as a service, whenever
they need to do stuff with XML data.

Presently cocoon has one single producer (input pipeline), which reads
files from the local filesystem. In other words the only type of input
cocoon accepts are files in the local filesystem. But there may be
remote files or dynamically constructed data - how can we make cocoon
accept those as input? Currently only by shadowy hacks
(ProducerFromRequest) or third-party tools (SOAP).

The output pipeline cocoon uses is the ServletResponse object. In other
words there is a need for an existing HTTP connection, otherwise nothing
can be output. If we want cocoon to send its output to a local file or a
mail pipeline, we must write an XSP page (or an XSP taglib or a
processor), which does that as a side-effect. In other words the output
always goes to the HTTP connection, even if we don't really need or want
it - anything else must be programmed as a side-effect.

I am not familiar with cocoon2, perhaps these issues have been adressed.
But I am wondering whether something like this can be realized for
cocoon1 as well. What do you think?

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Mime
View raw message