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.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
