Ulrich Mayring wrote:
>
> Paul Hammant wrote:
> >
> > Err, are we not talking baout mounting Cocoon inside Jo inside Phoenix?
>
> [Cc: to cocoon-dev list]
>
> Normally the webserver has to parse the request and then, after
> determining that the request is for the servlet engine, make a TCP/IP
> connection to it and pass the request on. The connection is a costly
> operation, even if on the same host. Then, the servlet engine needs to
> parse the request again in order to determine which servlet is
> responsible for it. In Jo's case the webserver can talk directly to the
> servlet engine, as they are one application. The servlet engine itself
> never makes a TCP/IP connection, it just starts a servlet in the same
> JVM. Now I can think of several possibilities:
>
> 1) Instead of starting a servlet, make Jo call various Cocoon-blocks
> (which implement Callable or somesuch interface)
> 2) Have Jo call a dispatcher servlet, that can then call the various
> Cocoon-blocks and also use other Avalon-Blocks.
> 3) Install Cocoon as a .war application under Jo.
>
> The third option is the easiest to implement, but you can only use
> Cocoon as a monolithic application and you cannot access it without a
> costly HTTP connection, even if you are in the same JVM.
>
> The first option requires changes in Jo and I don't think the Jo
> developer wants to introduce proprietary Phoenix connectors.
>
> So the second option seems to be best. It has the advantage that you
> only need to go over Jo and the Dispatcher servlet, when requests come
> in via HTTP from outside users. If you have a .sar application under
> Phoenix, then it can use the Cocoon-blocks directly.
>
> For example, we have a lot of asynchronous requests, which come in via
> email. They are stored in a MessageQueue and processed by various .sar
> applications. The result of the transaction is sent out via email again
> - it would be nice, if I could attach a dynamically generated PDF. So
> for that I'd like to have a "XML-->XSL(T|FO)" block, I probably don't
> care much about XSP, the Sitemap, generators and all the other bells and
> whistles Cocoon has. But the same block could also be used to serve
> dynamically generated PDFs to synchronous connections coming in over
> HTTP.
[sorry for crossposting, but this interests both communities, I think]
One question: you want to remove the connection overhead in order to
obtain Cocoon services and I agree that this is a "good thing"(tm).
Originally, Pier and I designed Cocoon2 to be an avalon block but
decided to move away from that since the APIs weren't solid enough.
Now, this said, please reread the above sentence: the key part is
"obtain cocoon services".
Cocoon is, like it or not, based on a request/response paradigm that is
modelled after HTTP.
Sure, the environment is abstract and I still believe that a Mailet
interface can be written around Cocoon to provide XML-based mail
handling capabilities of some sort, but we decided to focus on web
development.
So, my vision is that if you want "XML --> XSL(T|FO)" processing block,
you are going to create a behavioral interface that doesn't ask for a
particular Cocoon resource, but pushes the various streams into the
service and wants to obtain a result.
This is what we call "Subversion of Control"!
And it's evil since it twistes a bood IoC design in such a way that it
becomes a nightmare for users to understand and for developers to
manage.
So, my vote to the proposal "would you like to add block-like behavior
to Cocoon" is *heavily* dependent on what you want this block interface
to be.
If you want to model IoC behavior, then +1.
If you want some XML processing API, then -1.
There are people that believe that Cocoon can be turned into a service
and maintain its architectural efficiency and elegant design (i.e. the
Turbine people that say they support Cocoon just because they use it as
a XSLT tranformer!).
I simply do not and for the reason above: IoC means that you ask for a
resource to Cocoon and it knows what to do.
This is a design pattern that must not be altered in any way, under any
circumstance or Cocoon will be nothing different from
Xerces+Xalan+FOP+Batik.
I hope you guys understand my strong feelings about IoC.
If not so, please, make yourself heard because it's vital that we all
agree on something so basic.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
