cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <>
Subject [RT] Some notes about the "Real Blocks" issue
Date Wed, 13 Oct 2004 16:59:42 GMT

here are some notes I jotted down today while on the train and later on 
the plane, on my way back home from the GT, on the issues we discussed 
Monday WRT "Real Blocks", Butterfly, Kernel (Tani), Spring, blah blah 

Take it as just an outline to fill with your 
opinions/suggestions/critiques. As soon as it starts coalescing into 
something sensible, we should put it on the Wiki.

My ideas on what should be used _inside_ blocks are rather clear, but I 
especially need input on the thing (should we call it Tani, Kernel, 
something else?) that is supposed to contain blocks, manage their 
dependencies, make it possible for components defined in one block to 
refer to components defined in another block, etc. What will it look 
like, in practice?

Here we go:

- [ ] GT2004 notes
     - [ ] Two levels of containment
         - [ ] Intra-block
                   Defining components and wiring them together inside a
                   single block can be done with a dependency-injection
                   type of container. We can do a tentative
                   implementation using Spring.
         - [ ] Inter-block
                   There should be a container for blocks which should
                   provide block deployment, classloader isolation and
                   of course the means by which components defined in
                   one block can be wired to components defined in
                   another block.
     - [ ] Two kernels?
         - [ ] Phase 1 kernel
             - [ ] No downloading of blocks from repositories
             - [ ] Blocks statically defined, no live deployment
             - [ ] No hot swapping
             - [ ] No versioning
             - [ ] Might be used for development
             - [ ] Two kinds of blocks: Avalon (legacy) and Spring as
                       We need to support Spring (or Picocontainer,
                       HiveMind or something of our own doing) and
                       Avalon (for backward compatibilty) ONLY. ONE new
                       type of container will be supported, otherwise
                       it's just FS. This container should be
                       non-invasive, so that we might reuse components
                       if we, later on, decide to change the container's

         - [ ] Phase 2 kernel
             - [ ] Downloading of blocks from repositories
             - [ ] Live deployment without restarting
             - [ ] Hot swapping (maybe)
             - [ ] Versioning (for sure)
             - [ ] Might use something like GBeans from Geronimo
     - [ ] Configuration
         - [ ] The sitemap
                   The sitemap will define pipelines and possibly blocks
                   to be loaded at startup or, alternatively, parameters
                   for connecting to a naming service that will locate
                   remote blocks.

                   Use standards where possible for the naming service,
                   e.g. LDAP and/or JNDI.
         - [ ] The block context specification
                   The block context specification will define:

                   1. components hosted inside this block and their
                   dependencies a-la Spring
                   2. Interfaces provided by this block to the external
                   world (public contracts) [?]

     - [ ] Everything goes inside blocks
               Even core components, like the FileGenerator. Cocoon's
               new core is made up only of a sitemap processor and block

               Q: should a specific environment implementation (e.g.
               servlet, cli) be its own block, so that applications that
               don't need it won't load the block?

               Q: could the flowscript interpreter be its own block?
     - [ ] Geronimo/JMX?
               This thread:
               might provide some suggestions re the
               implementation of the kernel.
     - [ ] Plan of action
         - [ ] 1. Define some use cases
         - [ ] 2. Write tests
         - [ ] 3. Implement complete use cases in the simplest possible
                   Use a "Tracer Bullets" approach (see The Pragmatic
                   Programmer, item #10).
         - [ ] 4. Refactor mercilessly

Ugo Cei -
View raw message