cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject [RT] Distilling the requirements for Block Support
Date Fri, 18 Apr 2003 13:48:02 GMT
I want to come up with a base set of requirements to support "blocks".
A Block is defined as a functional peice of an application that is
comprised of one or more components.  Examples of a block could be
encapsulating a particular class of logic like: automated support for
integrating with an FTP server, processing text based requests, or
simply adding functionality to an application.

All three of these projects (I am copying Vincent because he is on
the D-Haven team, but is experiencing temporary Email problems) have
a defined need for blocks.

For Cocoon, they want to allow one developer to supply support for
Forums, or some other pluggable application logic, and then another
developer to use that, and provide their own look and feel so that
it integrates with the whole site.

For GUIApp, they want to allow the developer to extend your average
application with encapsulated blocks and incorporate the new menu
items, task bar items, and screens into the application.  The
requirements are somewhat different "Plug-ins" because it also
encapsulates fundamental things like Document Management or User

For Avalon, we need a consistent packaging for all our Excalibur
components so that both of these systems can automatically incorporate
those functions.  Also by developing the basic mechanisms to make
these plugins function, we are able to set up some basic rules and
make the integration of blocks as smooth as possible.

Both Cocoon and GUIApp need to be able to do resource inheritance,
but that need is not well defined in Avalon.  Although I think the
basic need for internationalization is a perfect example where Avalon
could set up the rules for resource inheritance.

There are different "plugin" mechanisms that we can learn from,
and adapt for our use.  For example, both Eclipse and IDEA use
the same basic mechanism for adding functionality to the respective
IDEs.  THere is a specified archive format (with JAR locations)
and a specified descriptor document.

You will find most plugin architectures similar.  However, there
does arise a problem as Eclipse developers found out.  How do you
handle the classloader needs when one plugin needs an incompatible
version of a library that another plugin provides--and still
integrate everything in the same user interface?

It's not an easy problem to solve, but using the versioning
specs in JARs we can at least catch conflicts.  If the JAR developer
doesn't play by the rules, you can always override that information
in the descriptor file.  That way we can manage JAR resources that
other folks release.

A common arrangement for plugin archives is like this:


It has its plusses and minuses, but it does deviate away from
how blocks should work.  We could *refer* to libraries and
resolve them automatically, or we could include them inside
the jar in a BLOCK-INF/ directory (kind of like SARs).

There are two things that an Avalon Block must do:  expose the
interfaces of services that it provides (or refer to them in
another block), and define the rules for integration.

I was thinking that if the Block archive has the interfaces
in a separate "interfaces" JAR, they can be exposed to the
kernel or other components more easily.  Also if each Block
has a "BlockKernel" or embedded container, it can establish
the rules for accessing the components inside that block.

This includes the notion of block dependencies and block
services--which is an extension of the concepts we already
have for components.  The only thing left would be "Block
Inheritance" if we feel that is a real need.

What are your thoughts?

"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".

-----Chris Rock

View raw message