On Apr 27, 2005, at 3:39 PM, Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:Our current (controversial ;) ) plan is to consider the sitemap and the component aspect of the original block proposal as separate concerns and (at least initially) solve them separately.
I propose less controversial plan.
As the first step, implement what you call "sitemap blocks", but call them simply "blocks". Own classloader, full classloading isolation, block protocol, exposing direct sitemap components: generators, transformers, serializers.
As the second step, implement "components block" *on top of* "sitemap blocks". This introduces second classloader (one is public, to share component interfaces, and one is private, to contain components implementation and libraries), and logic for managing classloader trees. Still call it simply "block".
Works for me. I think making distinctions among different types of blocks can only lead to confusion. After all, blocks are about component-izing Coccon. Much of the recent discussion has centered on the issues of extensibility and visibility. These issues, while important, are what makes the implementation of blocks complex. The incremental approach would be to develop block deployment and access mechanisms using the current sitemap mechanisms for controlling visibility, class loading, etc. Once that is accomplished the additional features can be incorporated one at a time. Evolving block features will likely lead to a better, more maintainable and extensible over all design. (Besides it will likely get real blocks here faster.)
Glen Ezkovich HardBop Consulting glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to worry about answers."
- Thomas Pynchon Gravity's Rainbow
