On Thu, 13 Sep 2001, Paul Hammant wrote:
> Hi, I'm an interloper from the Avalon-dev project.
>
> Cocoon, unless I am mistaken, is an application that is built on
> Avalon's Framework. It's curently deployed to one of a number of WAR
> file capable web servers nad runs in a request/reply context.
>
> In terms of additional coding effort, would it be possible to a have a
> version of Cocoon that was a pure server. Specifically, an Avalon
> Phoenix (block) server?
As Berin once outlined it shouldn't be a problem. The "Environment" the
Cocoon engine runs in is abstracted. I think the effort is to implement
a Phoenix/Service/Block environment for it. Most of the things
concerning environment start in the org.apache.cocoon.environment
package.
> Avalon Phoenix -What's that?
> ====================
>
> Well it's a full application server environment. It is also build on
> Avalon Framework, but can standalone and run multiple server
> applications (HTTP, FTP, NNTP, POP3 etc).
>
> What is the benefit?
> =============
>
> Well (over simplified), Cocoon could provide a service to other Phoenix
> blocks. That service would be the usual XSP/XSL experience i.e. styled
> output (ignoring PDF for a second). The output would be not HTTP based
> but pure XML. Consider another server, say a mail server, it could in
> phoenix's terms "depend" on the cocoon block and use Cocoon to create
> output for emails.
>
> There are other benefits too (list form for these):
>
> * One Cocoon server serving internally to multiple virtual web sites.
> - Each site uses a small servet to delegate to the Cocoon server.
>
> * Publishing Cocoon processing power to a SOAP or RMI API, by just
> "assembling" the correct blocks together.
>
> * Push based processing (phoenix has cron like blocks).
>
> What it would mean for the codebase
> =========================
>
> 1) Some more seperation between the cocoon engine and the the Servlet
> that invokes it.
Not sure if there is need for more separation because of the abstracted
environment.
> 2) Another servlet for the delegate form of Cocoon.
>
> 3) New phoenix service/block that takes some or all of the framework
> service/components and presents them to other blocks
Yeah, a cool vision.
> 4) New pheonix block (application) that depends on (3) to make
> plain-socket or RMI or SOAP server of Cocoon content.
>
> What this means for the existing deployment mechanism?
> ======================================
>
> Well, not a lot, you could still package Cocoon as a WAR file and deploy
> it like that. We're just broadening Cocoons horizons.
It sounds very cool to me. You'll have my +1 for it :)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
