cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Cocoon Blocks and internal web services
Date Wed, 03 Apr 2002 16:00:22 GMT
Mircea Toma wrote:

> I'm not saying that Phoenix blocks should be used to implement "Cocoon
> services", they are not meant for that. Cocoon could use Phoenix very much
> how James uses it (mailets), or if an app. server would be build using
> Phoenix (ejb deployment). Building on top of Phoenix doesn't mean that Cocoon
> cannot have it's own packaging scheme, I think it should because it addresses
> different concerns (web related).

Ok, I see your point now.

> ......
> > In case you don't want the installer to go around shopping for this,
> This is an example of what a Phoenix service could do for Cocoon. Going
> around and shop for blocks is not a web related service but a deployment
> service thus easily implemented using a Phoenix block.

Absolutely. I'm not saying that Cocoon shouldn't be Phoenix-aware or
Phoenix friendly, rather the opposite, but these are completely separate

> Things like: XML database, search engine, object store, servlet&JSP engines,
> or Cocoon container are well suited to be implemented as Phoenix blocks.

In fact, Cocoon itself (with no cocoon blocks on top) can well be seen
as one Avalon Block, but be easily integrated into Phoenix.
> > you
> > provide a single 'deployment descriptor' which indicates the entire
> > collection of URI where things are located on the web and the installer
> > goes there, grabs everything it needs and installs. But that's just one
> > xml file, not another package (it reduces the need for multipackaging
> > and makes it easier for us to publish blocks and create
> > web-service-driven repositories for behavior-based block shopping).
> ......
> > > This things are currently implemented in Phoenix, but in kernel space. I
> > > agree that these features should be implemented in application space,
> > > having a Cocoon specific implementation but service oriented.
> >
> > 'web service' oriented, I would say.
> >
> > My personal idea of a 'web service' is not just a way to have CORBA
> > implemented in XML over HTTP, but a way to provide *all* the information
> > one needs to use that web service. That requires not only logic, but
> > also all the resources (images, stylesheets, static pages, help
> > documents, etc..) that are required by the *user* of that service
> > (either a human directly or another web service)
> .......
> > Of course, I totally agree on the concept, but I don't think that
> > Phoenix is capable of providing solution for all our needs since Avalon
> > Blocks are very different from Cocoon Blocks (even if they aim use the
> > same design patterns).
> Of course they would be different, and they should be. All I'm saying is that
> Cocoon blocks would be deployed into a service (not web service) oriented
> framework like Phoenix is, where Cocoon container would be just another
> Phoenix service.

No, this is what I *don't* like. A cocoon block is not an extension of
an Avalon block, but it's a totally different thing.
> Please have a look at how James uses Phoenix, or how HP app. server uses
> their core service framework (very similar to Phoenix).
> Source code is available at:

I'm all in favor of using/reusing Phoenix where it does make sense, but
I don't think it does at this webapp level.

Anybody else wants to comment on this?

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

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

View raw message