Folks,
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 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
containers
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
implementation. - [ ] 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
deployer. 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:
http://thread.gmane.org/gmane.comp.java.springframework.devel/4910
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
way
Use a "Tracer Bullets" approach (see The Pragmatic
Programmer, item #10).
- [ ] 4. Refactor mercilessly
-- Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME cryptographic signature
