cocoon-dev mailing list archives

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

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

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
blocks
> 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
> http://www.ietf.org/rfc/rfc2396.txt.

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="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.

This all sounds promising.

Vadim

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


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message