cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Avoiding Cocoon Thermal Death
Date Wed, 20 Mar 2002 19:41:16 GMT
Antti Koivunen wrote:
> 
> Stefano Mazzocchi wrote:
> >
> <snipped-rationale but="read" and="agreed"/>
> >
> >           +---------------------------------------------+
> >           | 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.
> 
> Good. Forgive me, but I think this calls for a little ASCII art :)
> 
>                                     +-------------------------+
>                                     |       Cocoon Core       |
>          +------------------+       |   +-----------------+   |
>          | Client Interface | <-------> | Flow Controller |   |
>          +------------------+       |   +-----------------+   |
>                                     |            |            |
>    +----------------------------+   |   +-----------------+   |
>    | Block Management Interface | <---> | Block Container |   |
>    +----------------------------+   |   +-----------------+   |
>                                     +-------------------------+
> 
> I think this is more or less what we should aim for ('Flow Controller'
> here includes all sitemap/flowmap processing).

I would call this "pipeline controller" since I'd like to consider
'flow' as one possible way (the procedural way) to control the pipelines
(while sitemap is a more declarative way)

> There will probably be
> some overlap within the core components, and cocoon.xconf certainly
> won't disappear (but will become a lot more compact).

Exactly.
 
> >  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).
> 
> Yes, but as Michael already pointed out, it's worth noting that not all
> blocks are to be mounted on a 'visual' URI, i.e. some might just provide
> certain internal functionality.

Yes, I agree with this. We'll design this 'mounting' facility to be
configurable so that blocks might not contain any pipeline control and
just provide either resources or functionalities for other blocks.
 
> >  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).
> 
> All good. Eventually we'll undoubtedly have tools for managing these
> tasks and versioned block libraries.

Yes, that's the idea.
 
> > 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.
> 
> I think the rationale behind .WARs was to define 'complete' deployable
> web applications, which explains most of the design decisions, but I
> agree that this is not what we need for Cocoon (although it must be
> possible to prepackage a complete Cocoon installation inside a .war).

Yes, that is surely a nice goal, but it's pretty easy to keep the
concerns separated.

> > 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
> 
> Agreed.
> 
> >  b) The proposed archive extension is .cb,
> 
> Following up the discussion on the file suffix, of the current
> suggestions, I'd vote for '.cob'. Other possibilities include '.block',
> '.cblock' and '.cocoon'.

I completely agree with this vision.
 
> >  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
> 
> OK, no reason to break a pattern that works.
> 
> >   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.
> 
> OK, but another possibility would be
> 
>      block:role:/path/file
>      block:role:component
> 
> which might be more consistent with normal 'protocol handler' syntax,
> and perhaps the document referenced above (see the quote below).
> 
> <rfc-2396>
> 
> 3. URI Syntactic Components
> 
>     The URI syntax is dependent upon the scheme.  In general, absolute
>     URI are written as follows:
> 
>        <scheme>:<scheme-specific-part>
> 
>     An absolute URI contains the name of the scheme being used (<scheme>)
>     followed by a colon (":") and then a string (the <scheme-specific-
>     part>) whose interpretation depends on the scheme.
> 
> </rfc-2396>

Ok, no problem with that.
 
> > 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.
> 
> I would require URIs as identifiers and use 'roles' only for mappings
> (as already suggested by Michael). The block descriptor could of course
> suggest a default role for convenient deployment.

Yes, sounds like we reached a plan.
 
> Good work! This is clearly a step forward.

Thanks.

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