There is an astrophysical concept called 'Thermal Death': the details
are pretty hard to understand without a serious background in
thermodynamics, but the concept is very simple:
as closed systems get bigger, disorder increases and degrades energy
Thermal death is the point where all the energy is degraded so much that
isn't not possible to use it for anything, so the system dies, even if
the amount of energy that it has is the same.
- o -
I have the fear that Cocoon could die of thermal death, or, as less
theorical people would say, could 'collapse under its own weight'.
Why so?
Well, because the more feature we add, the more people we attract, the
more features will get added. So the system grows, but disorder with it
and the energy injected by these new contributions are degraded, slowing
down the evolution of the project.
What we need is a way to avoid the internal disorder to increase as we
add new stuff on top of Cocoon.
- o -
NOTE: on *top* of Cocoon.
The Cocoon internal architecture is very clean and elegant. The Avalon
patterns are showing their solidity day after day and all is well.
Cocoon is starting to show its deficiencies at the 'user level'.
There have been proposals about making user's roles, others about
automounting features, and so on... all go into the same direction: make
cocoon more modular at the user level.
If we don't do this, not only Cocoon will get bigger and bigger (and
start appearing more as a distribution of technologies, than a
framework), but users will find it harder and harder to modify it for
their specific needs.
We must change this, otherwise, the beautiful underlying architecture
will collapse under the weight of a bunch of features thrown on top with
less elegance, structure and order.
- o -
+---------------------------------------------+
| I propose the adoption of the Avalon Block |
| design pattern to modularize Cocoon's user |
| level and avoid the increase of disorder. |
+---------------------------------------------+
This, in short means:
1) Cocoon will be seen as an empty container. Provides basic framework
functionalities and block containment, but no feature on its own. This
explicitly resurrect the IoC pattern used in servlet engines, where the
functionality is packaged in servlets or webapps and the servlet engine
only provides services around that, with inverted control.
2) User functionality will be encapsulated in Cocoon Blocks. Using
Cocoon will mean to deploy one or more Cocoon Blocks on top of Cocoon.
These blocks will be *mounted* on a specific URI point and will be
called by Cocoon when they need to act (follows the IoC pattern).
3) These Cocoon Blocks contain file resources (raw or precompiled) and
compiled bytecode (as individual classes or JAR libraries).
4) Each block will have a manifest file that describes itself.
5) Cocoon will implement a mean for users to create their own blocks
and to deploy them, with great care to allow their hot-deployment (so,
withou the need to restart the system).
- o -
Many will find a great parallel between these Cocoon Blocks and WAR
files: it's right, WARs were a clear step forward and in the
installation of servlet-based web applications, but I was part of the
expert group that designed the concept, there are a few things that I
don't like:
1) the notion of 'deployment descriptor' breaks clean IoC. The package
should *NOT* contain any information about the external system, but only
information about its internals and, eventually, generic requirements on
services it needs to operate.
2) WARs are, themselves, monolythic. Instead, the Avalon Blocks exhibit
a polymorphic nature and can be 'componentized' in order to create a
higher functional environment.
3) because WARs are seen as applications and not modules, there is no
notion of dependencies, nor ability to perform a portable cross-war
communication, nor the ability to have polymorphic behavior of services
presented.
- o -
Ok, now I will describe how I see a cocoon block.
a) Cocoon Blocks are Zip files. Even if less efficiently compressed,
Zip archives have internal random-access features, unlike tar.gz,
moreover they are easy to read/write within java and are used for both
.jar and .war
b) The proposed archive extension is .cb,
c) The proposed MIME type is application/vnd.cocoon.block (to be
registered at IANA)
/ -> root of the block
/BLOCK-INF/ -> container for the block manifests (this directory is
shielded by Cocoon and will not be directly readable from the external,
just like it happens for /WEB-INF/ for WARs)
/BLOCK-INF/lib -> contains the libraries (.jar, .dll, .so)
/BLOCK-INF/classes -> contains the classes (.class, in their right
package location, as for WARs)
/BLOCK-INF/block.xinfo -> XML file that contains the block informations
along with component roles and configurations, sitemap/flowmap mounting,
and external block dependencies.
/** -> all of the remaining resources
d) a URI-based protocol will allow polymorphic access to cocoon blocks
and inter-block sharing of resources. The proposed syntax is
block(role):/path/file
and
block(role):component
for example
block(skin):/stylesheet/document2html.xslt
block(calendar):date-generator
NOTE: the above is compatile with the URI syntax as described in RFC
http://www.ietf.org/rfc/rfc2396.txt.
In case the block role is ambiguous, it will be used as a namespace
prefix, as in
<map:match ...>
<map:generate src="block(role):/path/file"
xmlns:role="http://www.role.com"/>
<map:transform src="block(role):/path/file"
xmlns:role="http://www.myrole.org"/>
</map:match>
if the block-based URI is used in non-namespaced syntax (for example, in
the flowmap), an API-based solution will be provided.
Ok, I think I went far enough.
Your turn.
--
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]
