If there is something I don't personally like about Cocoon it's the
feeling of 'monolithicity' that gives the cocoon.war file and the
problems that this creates.
Many people find a 12 Mb .war file a little too much and I perfectly
agree with them: people working 'on top' of cocoon (not inside cocoon),
would like a better way to *install* their stuff on top and not within
the war file.
The ideal scenario should be something like this:
1) install an empty cocoon (with only the core libraries it needs to
operate).
2) deploy cocoon web applications (CWA) on top.
In short: inherit the .war pattern and make Cocoon look similar to
Tomcat than to a servlet. (so, providing a solid IoC pattern of use).
- o -
I was part of the group who designed the .war concept and at that time
we greatly overlooked the concept of 'inter modularization' of .war
modules: servlet web applications were 'sealed' as applications, not
components. Interoperation of .war webapps was *not* taken into
consideration.... I believe this is the reason why there are tons of
'php' webapps and some of them interoperating (see www.horder.org) while
there are very .war applications that interoperate.
I don't want this to happen with Cocoon.
Like I stated previously, I'd like to see these .cwa archives as
'components' that must be assembled in order to provide a functionality.
This is the same pattern that avalon used: components and blocks.
Components are small-size clusters of classes that provide a single or a
small number of related services. Blocks are clusters of components that
provide a more high-level service.
Avalon components are used as-is inside Cocoon, and Cocoon itself can be
considered an Avalon Block (in fact, actually it's just an inteface away
to become one!) with Servlet API and CLI wrappers (other wrappers might
be useful in the future, like a Mailet wrapper, for example).
But the above is a code-oriented view of the architecture.
If we move into a web-oriented view, then each 'stylesheet' or
'document' can be seen as a 'transformation' component. A pipeline is
how they are connected together to operate. A cocoon webapp block can be
seen as the entire archive made with
- sitemap (xmap)
- documents (xml, stylesheets, pagesheets, images, etc..)
- cocoon components (classes)
- component configurations (xconf)
- libraries (jar, dll, so)
This RT is made to trigger discussion in the creation of:
1) an archive format (a-la .war)
2) a DTD for cwa deployment descriptors (a-la web.xml)
3) tools to create the package
4) tools to deploy the packages, check dependencies, guide installation
and configuration
The major difference between a .war archive and a .cwa archive will be
the their polymorphic nature: while a .war deployment descriptor is a
file that describes only the *internals* of the archive, a .cwa
deployment descriptor will have to include:
1) what 'behavior' the cwa component implements (indicated as a
versioned URI), similar to the java concept of classes implementing
interfaces
2) what other cwa components this component requires (if any), here the
'behavioral URI' is indicated, allowing polymorphism
Imagine a possible scenario of use:
1) you find a cool cocoon webapp to install on your site
2) you download the .cwa file
3) you deploy it on top of your cocoon, indicating where you want to
'mount' it in your web site URI space.
4) if a component that implements the same (versioned!) behavior is
already present in the system, a choice of overwriting or aborting is
given.
5) if not, the component is unpacked and installed and its dependencies
checked.
6) all the dependencies are checked, if a behavior is required by the
component but it's not found in the system, the deployer will connect to
the cocoon cwa database (hosted on xml.apache.org/cocoon/cwa or similar)
possibly using a web service and give the user choices about the
different implementations. The user is given the opportunity to install
its own implementation of that behavior.
7) when all dependencies are matched, the component is finally made
available.
But how do cwa components interoperate?
My idea is to come up with a protocol:
component[role]://path/resource
something like
<match pattern="**">
<generate type="mailbox" src="{1}"/>
<transform type="xslt" src="mail2document.xslt"/>
<transform type="xslt" src="[skin]:/document2html.xslt"/>
<serialize/>
</match>
comments?
--
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]
