Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <39492929.B823BE2@apache.org>
Date: Thu, 15 Jun 2000 21:06:17 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Battleplan?
References: <007701bfd5de$7b722f40$db0c8cd4@eddie>
 <39478BB6.ECF4110E@infoplanning.com> <3948170A.BBC25731@apache.org>
 <3948D4DE.BDFBF1C6@infoplanning.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Berin Loritsch wrote:
> 
> 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.

Yeah, I think that 

 org.apache.cocoon.Cocoon

should implement

 org.apache.avalon.Block

(so that Avalon can use it as a component and make it available to other
composers).

Cocoon2 will have has hooks for:

 - servlet (already implemented)
 - mailet (yet to be written)
 - command line (yet to be written)

the servlet hooks is implemented in 

 org.apache.cocoon.servlet.CocoonServlet

the mailet hook should be placed accordingly

 org.apache.cocoon.mailet.CocoonMailet

as well as the command line (where the static main() method is)

 org.apache.cocoon.offline.Cocoon

Question: I'm not sure I like these names.... anyone has better options?

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

The Mailet API implements a complete component model. You create
pipelines of mail "filters" and they also behave as "valves": they can
stop the processing if the authentication is invalid (and send back a
message to the sender or do whatever you like).

The component model also allows you to do mail authentication forgetting
about "what" the mail has attatched. So this is totally independent of
the Cocoon mailet and will be handled by the JAMES project.

I do see the concerns, but this was already taken into consideration
when we designed the Mailet API (yet to be finalized, BTW, so if you
guys have comments and suggestions, please, join the JAMES community and
help)

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

Yes. These connectors can be simple (RMI, for example) or very complex
(Tomcat calling an avalon-aware servlet that uses cocoon as a 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
> Cocoon.

Yes, this is one of the reasons why there are CocoonRequest and
CocoonResponse instead of using the servlet ones: to abstract it from
the different usages.
 
> 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.

No. The CocoonServlet itself is a "bridge" between the Servlet API and
the Cocoon API (which should be is very similar in functionality but
more abstract and XML oriented). The other blocks just need to access
the "Cocoon" block and work with that directly.
 
> 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?

Careful here. A BlockGenerator/BlockSerializer are nonsense. A generator
creates SAX events from internal logic. If this logic is avalon-aware,
so be it, but you don't know anything about a block so you can't
generalize it. For BlockSerializer is even worse: you do serialization
based on what comes in, not where you send it.

If an external block wishes to use Cocoon, it simply asks avalon for a
cocoon instance and _uses_ it by creating a CocoonRequest, a
CocoonResponse and send them to the returned cocoon instance. The
calling composer is responsible to "fake" this cocoon call and to
indicate the streams cocoon should use to read the request and write the
response.

DISCLAIMER: faking a request and calling Cocoon as a block will only be
used _rarely_, probably once or twice, not more than this. Why? well,
because Cocoon should be calling you not the other way around.
 
> 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).

Hmmmm, knowing the block name could create overlap between the avalon
configurations and the sitemap.... we should be able to have a sitemap
that doesn't need to change if you rename your blocks around.

The real contracts are the working interfaces implemented by the
blocks.... but something like

 block://org.apache.whatever.FancyPublisher/path/resource

could be a little too verbose... on the other hand, having something
like

 connector:smtp://ip-add:port/path/resource

wouldn't be of any use in case Cocoon is not called directly by a
connector, but from another block.

Anyway, let's not worry about this now, ok?

Cocoon2 will be used 60% as a servlet. If we add mailet and command line
we reach 99.99% that other 0.01% is block-behavior but I seriously doubt
anybody will use that. Cocoon will mainly use Avalon services and
components (it will mostly be a composer, rather than a component, its
working interfaces being servlets, mailet and command line)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------