cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <>
Subject RE: [RT] Avoiding Cocoon Thermal Death
Date Wed, 13 Mar 2002 16:14:39 GMT
> From: Stefano Mazzocchi []
> 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
> 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.

Isn't this about ever-growing world entropy?

<snip parts I agree with/>

>  / -> 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
> 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
> along with component roles and configurations, sitemap/flowmap
> and external block dependencies.

Shouldn't this be block.xml? (in parallel with web.xml).
And, roles and configurations could be stored in separate files, and
referenced but not included into block.xinfo.

>  /** -> all of the remaining resources
>   d) a URI-based protocol will allow polymorphic access to cocoon
> and inter-block sharing of resources. The proposed syntax is
>   block(role):/path/file

I do remember that sub-protocol also was proposed, but I forgot why it
was rejected...

> 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

Could you point to the page or chapter?

> 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=""/>
>   <map:transform src="block(role):/path/file"
> xmlns:role=""/>
>  </map:match>
> if the block-based URI is used in non-namespaced syntax (for example,
> the flowmap), an API-based solution will be provided.
> Ok, I think I went far enough.
> Your turn.

This all sounds promising.


> --
> 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