cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Battleplan?
Date Thu, 15 Jun 2000 13:06:38 GMT
Stefano Mazzocchi wrote:

> > > We need to consider how Cocoon 2 can be used from other applications.  Kevin
> > > Burton (no relation!) is interested in using Cocoon 2 in JetSpeed, so he can
> > > throw some input in there.
> >
> > If we are going to incorposate Cocoon as an Avalon Block (as well as the
> > servlet integration and command line integration), then we can use the
> > Avalon code to specify the semantics.
> I'm a little concerned on requiring an Avalon installation to install
> Cocoon2... but if Catalina is installed with Avalon, Cocoon2
> installation will be a piece of cake and we should aim to that.

It was Just-A-Thought (tm).  Avalon does have some cool things going
for it--but the more I look at it, I agree.  Cocoon is built in the Servlet
architecture first.  That means that we could still throw in some hooks
so that the rest of an Avalon server can directly access Cocoon (much
like a command line interface would allow).  We should have our own
Main class.

My proposal:
Define an interface that facilitates the use-cases specified below, and
implements Block.  The Main class uses this interface (just like any
other Avalon-aware system).  This maintains ease of maintenance,
and a consistent action for each method (it is not implemented in multiple
locations).  Cocoon still remains Avalon-aware, does not require an
Avalon installation, and has its own CLI.

> > Anybody got some good Use-Cases?
> I plan to create a Cocoon Mailet interface for JAMES to use XML
> publishing capabilities to process emails. Something like you send a
> document attatched to your mail and if the schema is matched, it's
> transformed with XSLT and the serialized is sent instead as attachment.
> Maybe silly, I know, but B2B stuff might find it useful. You send the
> XML data attatched to the mail, Cocoon "adapts" it to your internal
> schema, another mailet places this into your database.

Actually, this kind of Mailet B2B solution may be very dangerous.  There
are all kinds of security and authentication issues.  But I can see the potential
for using Cocoon in a B2B framework (my company's primary business area
is retail/vendor business automation).  I am working on a proprietary data
management/transformation system that would be built on the Avalon system,
and would definitely benefit from the Cocoon framework.  Currently, until
C2 is out, I am forced to reimplement some of the functionality myself.

> > How would Cocoon be used as an outside entity?
> So far, I picture usage from
>   - http
>   - smtp
>   - soap
> and some wild cases like in "JAM" (Java Answering Machine) [a project
> Pier started but never had time to continue... you can find pieces of it
> under the whiteboard CVS module under java.apache] where VoiceML is
> processed by Cocoon thru a voice recognition filter and thru the Java
> serial interface directly to your modem or fax machine. But this could
> be easily layered on top of HTTP as well, so consider this a special
> HTTP case. The same could be said for SOAP.

So basically, we have different connectors that access the Cocoon Block.
Based on the sitemap and the parameters passed to the Block, Cocoon
transforms the input and sends it back out through the connector that accessed

In order to facilitate this type of thing, we would need a ConnectorGenerator
to generate the original markup comming in from the Connector (http, soap,
smtp, etc).  We would also need a ConnectorSerializer to send the information
back through the Connector that sent us the informaiton.  In the sitemap, the
URI for something like that might have to specify IP address and port.

We could use a thin wrapper to the Block and create a BlockGenerator and
a BlockSerializer so that if C2 is properly Avalon-aware, the accessing block
uses the Interface/wrapper class and directly sends/receives the SAX2 events.
We do want speed right?

The accessing Block/Mailet/Composer/etc. worries about the semantics.  We
just need to define the URI semantics so that we don't have to modify the sitemap
for these special cases.  Something like "block://block-name" to specify the
originating call from a block or "connector:smtp://ip-addr:port" if we go the
connector route.  (I like the block methodology better).

View raw message